JP5246031B2 - 業務フロー処理プログラム、方法及び装置 - Google Patents

Description

本技術は、業務プロセス分析技術に関する。

業務プロセス・リエンジニアリング（ＢＰＲ：Business Process Re-engineering）のために現在企業で運用中の業務システムの分析を行う必要がある。このため、以下のような技術が存在している。

すなわち、（１）異なる業務システムに配置される各アプリケーションの実行状態を示す情報であるイベントデータを、各アプリケーションに応じた方法で収集し、イベントキューにキューイングする。なお、ここでイベントとは、業務システム内で、ある業務が実行されたことを示すものであり、業務の開始、終了時間、および関連属性を含んだデータである。イベントデータは、各業務システムに配置されたイベント抽出定義に従って、業務システム毎のイベントデータ抽出用のアプリケーションによって抽出される。各業務システム内で、抽出されたイベント情報を共通のＸＭＬ（eXtensible Markup Language）形式に変換し、イベントデータを管理するイベント管理装置のイベントキューにキューイングする。このキューイングには、例えばＪＭＳ（Java（登録商標） Message Service）等が利用される。

（２）イベント管理装置内で、イベントキュー内にキューイングされたイベント情報について、業務データ毎にまとめ、業務データ間を関連付けてイベント管理データベース（ＤＢ）内に蓄積する。ここで、業務データとは、あるまとまった単位の業務の間で共有されるデータを意味する。（３）入力された検索条件（例えば、イベント発生期間、関連属性等）に基づいて、業務データの絞込みを行う。（４）絞り込まれた業務データに関連するデータをツリーで展開して表示し、任意のデータからの処理の追跡を行う。（５）ツリーで展開された業務データに関連するイベントを検索し、このイベントに関連する業務をトラッキングビューで図示して、現在の業務の流れの実行状況を表示する。ここで、トラッキングとは、あらかじめ定義された業務システム間を跨ぐ業務全体の流れである業務プロセスのうち、どの業務が実行され、どの業務が実行されていないかを確認する手法をいう。

このような技術では、業務システム毎にイベントデータ抽出用のアプリケーションを導入する必要があり、業務システムに改変を加えるか又は業務実行に不要な負荷を与えることとなる。

その対策として、業務システムに改変を加えず且つ業務実行に不要な負荷を与えることなく、業務システムのデータベースのバックアップデータや業務ログデータ等を用いた分析の方法が存在している。すなわち、データベース中の複数のテーブルについて、各々のテーブルにおける項目毎に、当該項目中の値毎の出現回数に基づく値である項目スコアを算出する項目評価ステップと、複数のテーブルの中から互いに異なるテーブルを関連元テーブル及び関連先テーブルとして選択し、関連元テーブル中の項目である関連元項目と関連先テーブル中の項目である関連先項目とを選択し、関連元項目と関連先項目の組み合わせを関連として生成する関連生成ステップと、関連生成ステップにより生成された関連毎に、関連先項目における関連元項目中の値毎の出現回数と関連元項目の項目スコアと関連先項目の項目スコアとに基づく値である関連スコアを算出する関連評価ステップとを実行することで、複数のテーブルにおける項目間の関連を検出することができる。

ここで、例として、各テーブル名をイベント名とし、日時データを格納している項目をイベントの発生日時であるタイムスタンプ項目とし、前記の分析で抽出された、関連元項目及び関連先項目を、各々イベントＩＤ及び関連ＩＤの項目とすることで、イベントインスタンスのデータを抽出することが可能となる。

一方、イベント名、イベントＩＤ、タイムスタンプから構成されるレコードの集積であるイベントログから、イベント間のフローのモデルを抽出する先行技術として、隣接した前後関係・因果関係・並列・無関係を判定するルールを全フローインスタンスに適用するαアルゴリズムがある。αアルゴリズムは、ルールベースであるため、運用中の業務システムから取得した実データに存在するノイズに弱く、また対象業務のワークフローに繰返し・手戻りが含まれる場合には、原理的に間違った判定を行うため適用することができないという問題がある。

特開２００５−１１５４９４号公報 特開２００８−２７０７２号公報

Ana Karla Alves de Medeiros, "Process Mining: Control-Flow Mining Algorithms", [Online] [平成２１年３月８日検索］、インターネット（URL:http://prom.win.tue.nl/research/wiki/processminingcourse）

業務システムのデータベースのバックアップデータや業務ログデータに対して、上記の技術を用いることで、イベントインスタンス（のレコード）及びそれら（のレコード）間の対応関係を抽出することができ、イベントＩＤを共有または、関連ＩＤを介して対応関係のあるイベントインスタンス（のレコード）を、単純に発生日時に基づき直列的に接続することで作成したプロセスインスタンスは、各イベントインスタンスが属するイベントクラスに対応する実際の業務の業務フローが、主要経路と当該主要経路から分岐する並列経路とを含むものである場合には、実際の業務フローには対応しないものとなる。すなわち、主要経路で発生するイベントインスタンスと並列経路で発生するイベントインスタンスとを機械的に発生日時順に連結した場合には、業務上は意味を持たない見かけ上の遷移を含むことになる。

従って、本技術の目的は、特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための技術を提供することである。なお、イベント間遷移の遷移元のイベントを発側イベント、遷移先のイベントを着側イベントと呼称することとする。

本業務フローデータ処理方法は、（Ａ）特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各プロセスインスタンスに含まれるイベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、（Ｂ）統計情報格納部に格納されている各イベント間遷移発生頻度を、該当する発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、発側イベントクラスに属するイベントインスタンスが発生した場合に着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各イベントクラスに属するイベントインスタンスの発生頻度を全種のイベントクラスに属するイベントインスタンスの発生頻度の総和で除することによって、各イベントクラスに属するイベントインスタンスの発生確率を算出し、統計情報格納部に格納するステップと、（Ｃ）特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する条件付き確率と判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの発生確率とを用いて規定される評価式の値を、統計情報格納部に格納されている各イベント間遷移発生頻度に係る各遷移について算出し、統計情報格納部に格納するステップと、（Ｄ）統計情報格納部に格納されている、各遷移の評価式の値のうち所定の閾値未満となっている評価式の値に係る遷移を見かけ上遷移として検出するステップとを含む。

特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出することができるようになる。

本発明の実施の形態における機能ブロック図である。 並列処理推定部の機能ブロック図である。 （ａ）乃至（ｄ）は、本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態におけるメインの処理フローを示す図である。 （ａ）は、抽出データ例である受注ＤＢのスキーマ情報、（ｂ）は、受注ＤＢのレコード群を示す図である。 （ａ）は、抽出データ例である生産ＤＢのスキーマ情報、（ｂ）は、生産ＤＢのレコード群を示す図である。 （ａ）は、抽出データ例である手配ＤＢのスキーマ情報、（ｂ）は、手配ＤＢのレコード群を示す図である。 （ａ）は、抽出データ例である配送ＤＢのスキーマ情報、（ｂ）は、配送ＤＢのレコード群を示す図である。 （ａ）は、抽出データ例である品番ＤＢのスキーマ情報、（ｂ）は、品番ＤＢのレコード群を示す図である。 （ａ）は、ＣＳＶ形式の受注ＤＢのデータ例を示し、（ｂ）は、受注ＤＢのデータをテーブル化した例を示す図である。 （ａ）は、ＣＳＶ形式の生産ＤＢのデータ例を示し、（ｂ）は、生産ＤＢのデータをテーブル化した例を示す図である。 （ａ）は、ＣＳＶ形式の手配ＤＢのデータ例を示し、（ｂ）は、手配ＤＢのデータをテーブル化した例を示す図である。 （ａ）は、ＣＳＶ形式の配送ＤＢのデータ例を示し、（ｂ）は、配送ＤＢのデータをテーブル化した例を示す図である。 （ａ）は、ＣＳＶ形式の品番ＤＢのデータ例を示し、（ｂ）は、品番ＤＢのデータをテーブル化した例を示す図である。 タイムスタンプ判定処理の処理フローを示す図である。 タイムスタンプ確度スコア表の一例を示す図である。 イベントＩＤ及び関連ＩＤ候補判定処理の処理フローを示す図である。 イベントＩＤ・関連ＩＤ候補確度スコア表の一例を示す図である。 イベント名判定処理の処理フローを示す図である。 タイムスタンプが複数含まれるテーブルの一例を示す図である。 （ａ）乃至（ｅ）は、図１９のテーブルをイベント毎に複数のテーブルとして分割した例を示す図である。 スキーマ情報が存在する場合における、受注ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 ＣＳＶ形式のデータの場合における、受注ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 スキーマ情報が存在する場合における、生産ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 ＣＳＶ形式のデータの場合における、生産ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 スキーマ情報が存在する場合における、手配ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 ＣＳＶ形式のデータの場合における、手配ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 スキーマ情報が存在する場合における、配送ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 ＣＳＶ形式のデータの場合における、配送ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 スキーマ情報が存在する場合における、品番ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 ＣＳＶ形式のデータの場合における、品番ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 イベント候補データの各要素に対する選択結果の一例を示す図である。 スキーマ情報が存在する場合において受注ＤＢのデータから生成したイベント候補データの一例を示す図である。 ＣＳＶ形式のデータの場合において受注ＤＢのデータから生成したイベント候補データの一例を示す図である。 スキーマ情報が存在する場合において生産ＤＢのデータから生成したイベント候補データの一例を示す図である。 ＣＳＶ形式のデータの場合において生産ＤＢのデータから生成したイベント候補データの一例を示す図である。 スキーマ情報が存在する場合において手配ＤＢのデータから生成したイベント候補データの一例を示す図である。 ＣＳＶ形式のデータの場合において手配ＤＢのデータから生成したイベント候補データの一例を示す図である。 スキーマ情報が存在する場合において配送ＤＢのデータから生成したイベント候補データの一例を示す図である。 ＣＳＶ形式のデータの場合において配送ＤＢのデータから生成したイベント候補データの一例を示す図である。 図１９の起票に関するイベント候補データの一例を示す図である。 図１９の承認に関するイベント候補データの一例を示す図である。 図１９の発注に関するイベント候補データの一例を示す図である。 図１９の納品に関するイベント候補データの一例を示す図である。 図１９の検収に関するイベント候補データの一例を示す図である。 イベントデータ及びイベント間関係ツリーの一例を示す図である。 イベントデータからのプロセスインスタンス生成を説明するための図である。 プロセスインスタンスの一例を示す図である。 主要及び例外フローの抽出処理を説明するための図である。 図４８に示したプロセスインスタンスを重ね合わせる場合の表示例を示す図である。 （ａ）乃至（ｃ）は、図４８に示したプロセスインスタンスを、主要フローと例外フローとに分類した場合の表示例を示す図である。 従来技術の問題を説明するための図である。 従来技術の問題を説明するための図である。 従来技術の問題を説明するための図である。 図５６の業務フローの中で、業務上の並列処理を含む業務フローのみを抽出したものを示す図である。 主要経路と当該主要経路から分岐した並列経路とを含むプロセスインスタンスの一例を示す図である。 図５１のプロセスインスタンス・グループＡ乃至Ｅを図５４のプロセスインスタンスに置換した場合における主要フロー及び例外フローの分類の一例を示す図である。 業務上の並列処理を含む業務フロー全体を示す図である。 図５５に示したプロセスインスタンスを重ね合わせた場合の全体フローを示す図である。 並列処理推定処理の処理フローを示す図である。 イベント間遷移頻度表の作成方法を模式的に示した図である。 イベント間遷移頻度表の一例を示す図である。 イベント間遷移頻度表の一部分を示す図である。 各イベントの発生確率の算出を模式的に示す図である。 条件付き確率の算出を模式的に示す図である。 各イベントの発生確率の一例を示す図である。 条件付き確率表の一例を示す図である。 事象の独立を説明するための図である。 評価指標値の算出例を示す図である。 並列処理推定処理の処理フローを示す図である。 並列処理該当プロセスインスタンスデータ格納部に格納されるデータの一例を示す図である。 並列処理推定処理の処理フローを示す図である。 代替遷移の設定について説明するための模式図である。 代替遷移の設定について説明するための模式図である。 並列処理推定処理の処理フローを示す図である。 見かけ上遷移を削除した場合のプロセスインスタンスの一例を示す図である。 見かけ上遷移の代替遷移を設定した場合のプロセスインスタンスの一例を示す図である。 モデルデータ格納部に格納されるデータの一例を示す図である。 フロー表示処理の処理フローを示す図である。 図５５に示したプロセスインスタンスの主要フローを重ね合わせた場合の一例を示す図である。 コンピュータ装置の機能ブロック図である。

図１Ａ及び図１Ｂに、本発明の一実施の形態に係る業務システム分析装置の機能ブロック図を示す。本実施の形態に係る業務システム分析装置は、単数または複数の解析対象システムから収集されたデータ（所定期間において生成されたデータベースのレコード群、ログデータ、ネットワークＤＢ（ＮＤＢ）のレコード群、ジャーナルなど）を格納する分析対象データ格納部１と、分析対象データ格納部１からイベント候補データを生成するイベント候補データ生成部３と、イベント候補データ生成部３により生成されたイベント候補データを格納するイベント候補データ格納部５と、ユーザとのインターフェースとなる入出力部１１と、入出力部１１を介してユーザの指示を受け付けイベントデータを生成するイベントデータ生成部７と、イベントデータ生成部７により生成されたイベントデータを格納するイベントデータ格納部９と、イベントデータ格納部９に格納されているイベントデータからプロセスインスタンスを生成するプロセスインスタンス生成部１３と、プロセスインスタンス生成部１３によって生成されたプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部１５と、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスのデータを用いて並列処理に由来する見かけ上の遷移を検出し、それらを含むプロセスインスタンスを抽出し、該当プロセスインスタンスのフローを見かけ上の遷移を削除した上で推定した並列処理の遷移を追加することで修正する並列処理推定部１７と、並列処理推定部１７によって修正されたプロセスインスタンス及び並列処理推定部１７の処理対象とならなかったプロセスインスタンスのデータを格納する並列処理推定後プロセスインスタンスデータ格納部１９と、並列処理推定後プロセスインスタンスデータ格納部１９に格納されているプロセスインスタンスをイベントの並び方に基づき分類して発生数をカウントするプロセスインスタンス分類処理部２１と、プロセスインスタンス分類処理部２１の処理結果を格納するモデルデータ格納部２３と、モデルデータ格納部２３に格納されているデータを用いて業務フローを表示するために必要な処理を実施するプロセス表示処理部２５とを含む。

なお、入出力部１１は、イベント候補データ生成部３、プロセスインスタンス生成部１３、並列処理推定部１７、プロセス表示処理部２５についても、ユーザとのインターフェースとして動作する。また、各処理部は、処理結果などを読み出して入出力部１１を介してユーザに提示するなどの処理を実施することもある。

また、イベント候補データ生成部３は、タイムスタンプ処理部３１と、イベントＩＤ・関連ＩＤ候補処理部３２と、イベント名処理部３４と、スコア表格納部３５とを有する。

また、図１Ｂに示すように、並列処理推定部１７は、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスにおけるイベント発生状況から各種統計データを算出する統計情報抽出部１７１と、統計情報抽出部１７１によって算出された統計情報を格納する統計情報格納部１７３と、統計情報格納部１７３に格納されているデータを用いてプロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスの構成要素として存在しているが実際の業務上は発生していないと推定される遷移である見かけ上遷移を検出する見かけ上遷移検出部１７５と、見かけ上遷移検出部１７５によって検出された見かけ上遷移を含むプロセスインスタンスを検出して当該プロセスインスタンスにおける見かけ上遷移を削除する見かけ上遷移削除部１７７と、見かけ上遷移削除部１７７によって抽出された見かけ上遷移を含むプロセスインスタンスのデータを格納する並列処理該当プロセスインスタンスデータ格納部１８１と、並列処理該当プロセスインスタンスデータ格納部１８１に格納されているデータを用いて見かけ上遷移の代わりに設定すべき遷移を特定する代替遷移決定処理部１７９とを有する。

次に、業務システム分析装置の大まかな処理内容について図２（ａ）乃至（ｄ）を用いて説明する。まず、イベント候補データ生成部３は、分析対象データ格納部１に格納された業務システムについてのデータからイベント候補データを生成する。イベント候補データの一例を図２（ａ）に示す。図２（ａ）の例では、例えば１つのテーブル（例えばデータベース）から、イベント名と、日時（イベントの発生日時であるタイムスタンプ）と、それ以外の第１の値（値１）と、第２の値（値２）などを含むレコード群が抽出されるようになっている。すなわち、イベント名やタイムスタンプ、それ以外にイベントＩＤや関連ＩＤの候補となるデータ・フィールドが特定される。

次に、イベントデータ生成部７は、イベント候補データ格納部５に格納されているイベント候補データからイベントデータを生成する。イベントデータの一例を図２（ｂ）に示す。図２（ｂ）の例では、複数のテーブル（例えばデータベース）から、イベント名、日時（イベントの発生日時であるタイムスタンプ）、イベントＩＤ（ここではＩＤ１）及び他の値を含むレコード群と、イベント名、日時（タイムスタンプ）、ＩＤ１及びＩＤ２などを含むレコード群とが抽出される。そして、第２のイベントクラス（すなわち、イベントの種類）のレコードの関連ＩＤであるＩＤ２のフィールド値が、第１のイベントクラス（すなわち、イベントの種類）のレコードのイベントＩＤであるＩＤ１のフィールド値のいずれかの値をとることにより、第２のイベントクラスの各々のレコード（すなわちイベントインスタンス）が、第１のイベントクラスのどのレコード（すなわちイベントインスタンス）と関連しているかが特定される。このようなイベント間の関連などを抽出する処理自体は、本実施の形態における主要部ではなく、例えば特開２００８−２７０７２号公報に既に開示されている。

その後、プロセスインスタンス生成部１３は、イベントデータ格納部９に格納されているイベントデータからプロセスインスタンスのデータを生成する。プロセスインスタンスの一例を図２（ｃ）に示す。図２（ｃ）の例では、４つのプロセスインスタンスが例示されており、各々のプロセスインスタンスには、一連のイベントインスタンス（具体的なイベント）が含まれている。すなわち、例えば「受注」「起票」「納品」「検品」といったイベントクラスに属する連続するイベントインスタンス（具体的なイベントであり特定のレコードに対応するイベント）でプロセスインスタンスが構成される。ただし、プロセスインスタンスに含まれるイベントインスタンスは、すべてのイベントクラスに由来する必要はなく、ひとつのイベントクラスに属するイベントインスタンスが複数含まれていても良い。なお、プロセスインスタンス生成処理自体は、本実施の形態における主要部ではなく、例えば、米国特許公開公報２００５／０７６０５９Ａ１のような業務プロセストラッキング方法等を用いることができる。

そして、プロセスインスタンスのデータを、並列処理推定部１７及びプロセスインスタンス分類処理部２１によって処理をして、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータからプロセスフロー（業務フローとも呼ぶ）のデータを生成して、入出力部１１を介して表示装置に表示する。プロセスフローの一例を図２（ｄ）に示す。図２（ｄ）の例では、プロセスインスタンスが集約されて特定される業務フローが示されている。

次に、図１Ａ及び図１Ｂに示した業務システム分析装置の処理の詳細を図３乃至図７７を用いて説明する。まず、ユーザは、業務システムにおける解析対象テーブルの指定を行い、そのデータをコピーして分析対象データ格納部１に格納させる（図３：ステップＳ１）。例えば、受注ＤＢ、生産ＤＢ、手配ＤＢ、配送ＤＢ、品番ＤＢが指定され、所定期間において生成され蓄積されていたレコード群をコピーして、分析対象データ格納部１に格納する。なお、これらのＤＢがリレーショナルデータベースであれば、スキーマ情報をもコピーして、分析対象データ格納部１に格納しておく。本ステップについては、予めユーザがコンピュータを操作して行う処理であるから、図３では点線ブロックで示している。

例えば受注ＤＢがリレーショナルデータベースである場合には、図４（ａ）のようなスキーマ情報と図４（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図４（ａ）に示したスキーマ情報の例では、フィールド１乃至４のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図４（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである受注番号が登録され、フィールド３には地域が登録され、フィールド４には受注内容が登録されることが分かる。具体的には図４（ｂ）のようなレコード群となるが、図４（ａ）のようなスキーマ情報を得れば、図４（ｂ）のようなレコード群の内容を容易に解釈することができる。

同様に、生産ＤＢがリレーショナルデータベースである場合には、図５（ａ）のようなスキーマ情報と図５（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図５（ａ）に示したスキーマ情報の例では、フィールド１乃至５のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図５（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである生産番号が登録され、フィールド３には副キーである受注番号が登録され、フィールド４には副キーである品番が登録され、フィールド５には納期が登録されることが分かる。具体的には図５（ｂ）のようなレコード群となるが、図５（ａ）のようなスキーマ情報を得れば、図５（ｂ）のようなレコード群の内容を容易に解釈することができる。

また、手配ＤＢがリレーショナルデータベースである場合には、図６（ａ）のようなスキーマ情報と図６（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図６（ａ）に示したスキーマ情報の例では、フィールド１乃至５のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図６（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである手配番号が登録され、フィールド３には副キーである受注番号が登録され、フィールド４には副キーである品番が登録され、フィールド５には納品先が登録されることが分かる。具体的には図６（ｂ）のようなレコード群となるが、図６（ａ）のようなスキーマ情報を得れば、図６（ｂ）のようなレコード群の内容を容易に解釈することができる。

さらに、配送ＤＢがリレーショナルデータベースである場合には、図７（ａ）のようなスキーマ情報と図７（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図７（ａ）に示したスキーマ情報の例では、フィールド１乃至４のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図７（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである手配番号が登録され、フィールド３には副キーである配送便が登録され、フィールド４に納品先が登録されることが分かる。具体的には図７（ｂ）のようなレコード群となるが、図７（ａ）のようなスキーマ情報を得れば、図７（ｂ）のようなレコード群の内容を容易に解釈することができる。

また、品番ＤＢがリレーショナルデータベースである場合には、図８（ａ）のようなスキーマ情報と図８（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図８（ａ）に示したスキーマ情報の例では、フィールド１及び２のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図８（ａ）から、フィールド１には主キーである品番が登録され、フィールド２には品名が登録されることが分かる。具体的には図８（ｂ）のようなレコード群となるが、図８（ａ）のようなスキーマ情報を得れば、図８（ｂ）のようなレコード群の内容を容易に解釈することができる。

一方、受注ＤＢのデータをＣＳＶ形式で取得した場合には、図９（ａ）に示すようなデータが分析対象データ格納部１に格納される。図９（ａ）の例では、日時、受注番号、地域及び受注内容というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図９（ａ）をわかりやすくするためにテーブル形式にすると図９（ｂ）に示すようになる。すなわち、日時の列と、受注番号の列と、地域の列と、受注内容の列とを含むテーブルとなる。スキーマ情報はないので、データは皆文字列として格納される。また、キー設定データはない。

同様に、生産ＤＢのデータをＣＳＶ形式で取得した場合には、図１０（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１０（ａ）の例では、日時、生産番号、受注番号、品番及び納期というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１０（ａ）をわかりやすくするためにテーブル形式にすると図１０（ｂ）に示すようになる。すなわち、日時の列と、生産番号の列と、受注番号の列と、品番の列と、納期の列とを含むテーブルとなる。

また、手配ＤＢのデータをＣＳＶ形式で取得した場合には、図１１（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１１（ａ）の例では、日時、手配番号、受注番号、品番及び納品先というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１１（ａ）をわかりやすくするためにテーブル形式にすると図１１（ｂ）に示すようになる。すなわち、日時の列と、手配番号の列と、受注番号の列と、品番の列と、納品先の列とを含むテーブルとなる。

さらに、配送ＤＢのデータをＣＳＶ形式で取得した場合には、図１２（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１２（ａ）の例では、日時、手配番号、配送便及び納品先というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１２（ａ）をわかりやすくするためにテーブル形式にすると図１２（ｂ）に示すようになる。すなわち、日時の列と、手配番号の列と、配送便の列と、納品先の列とを含むテーブルとなる。

また、品番ＤＢのデータをＣＳＶ形式で取得した場合には、図１３（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１３（ａ）の例では、品番及び品名というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１３（ａ）をわかりやすくするためにテーブル形式にすると図１３（ｂ）に示すようになる。すなわち、品番の列と、品名の列とを含むテーブルとなる。

業務システム分析装置の例えばイベント候補データ生成部３は、全ての解析対象テーブルについて処理したか判断する（ステップＳ３）。未処理の解析対象テーブルが存在する場合には、未処理の解析対象テーブルを１つ特定する（ステップＳ５）。そして、タイムスタンプ判定処理を実施する（ステップＳ７）。このタイムスタンプ判定処理については図１４及び図１５を用いて説明する。

まず、イベント候補データ生成部３のタイムスタンプ処理部３１は、分析対象データ格納部１から、解析対象テーブルにおいて未処理のフィールドを１つ特定する（図１４：ステップＳ３１）。そして、分析対象データ格納部１において解析対象テーブルのスキーマ情報が使用可能となっているか判断する（ステップＳ３３）。

スキーマ情報が使用可能となっている場合には、スキーマ情報において処理対象フィールドについてのデータ部分を特定し、その中で処理対象フィールドのデータ型がタイムスタンプ型であるか否か判断する（ステップＳ３５）。処理対象フィールドのデータ型がタイムスタンプ型ではない場合にはステップＳ３９に移行する。例えば、図９（ａ）乃至図１３（ａ）のようなデータを処理する場合にはスキーマ情報はないので、ステップＳ３９に移行する。

一方、処理対象フィールドのデータ型がタイムスタンプ型であると判断された場合には、処理対象フィールドのタイムスタンプ判定を「確定」と設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ３７）。そして、処理はステップＳ４３に移行する。

例えば、図４（ａ）のようなスキーマ情報の場合、フィールド１のデータ型がタイムスタンプ型であるので、フィールド１が処理対象フィールドであれば、タイムスタンプ判定＝「確定」と設定される。図５（ａ）のようなスキーマ情報の場合、フィールド１のデータ型がタイムスタンプ型であるので、フィールド１が処理対象フィールドであれば、タイムスタンプ判定＝「確定」と設定される。図６（ａ）及び図７（ａ）についても同様である。図８（ａ）の場合には、全フィールドについて、ステップＳ３５からステップＳ３９に移行する。

ステップＳ３３でスキーマ情報が使用不能と判断された場合又は処理対象フィールドのデータ型がタイムスタンプ型でない場合、スコア表格納部３５に格納されているタイムスタンプ確度スコア表を参照して、スキーマ情報における処理対象フィールドの該当データ部分、処理対象フィールドのフィールド名を表すラベルデータ、及び処理対象フィールドのフィールド値から確度を特定する（ステップＳ３９）。

タイムスタンプ確度スコア表の一例を図１５に示す。図１５の例では、「フィールドのデータ型が可変長文字列」であれば確度スコアは１（％）と設定され、「フィールドのデータ型が実数」であれば確度スコアは５（％）と設定され、フィールド名の末尾が「時刻」「時間」などであれば確度スコアは９０（％）と設定され、フィールド名の末尾が「月日」「日」などであって時刻などが含まれない場合であれば確度スコアは７０（％）と設定され、フィールド名に「予定」「納期」など将来の時期を指定する場合であれば確度スコアは１０（％）と設定され、フィールド値の文字列に年号（記号）、「／」「：」「’」「．」「−」、数字、空白といった時間に関連する文字以外の文字が含まれている場合には確度スコアは５（％）と設定され、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」の形式であれば確度スコアは９０（％）と設定され、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ」の形式であれば確度スコアは７０（％）と設定され、フィールド値に同一となるものが含まれていれば確度スコアは３０（％）と設定され、該当する項目がなければ確度スコアは５０（％）と設定される。

例えば、図４（ａ）のようなスキーマ情報で図４（ｂ）のようなレコード群の場合、フィールド２については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。フィールド３についても同様に、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。さらに、フィールド４については、データ型が可変長文字列であるので、確度スコア１（％）と特定される。なお、フィールド４については、フィールド値に時間に関連する文字以外の文字も含まれているので、タイムスタンプ確度スコア表において複数項目に該当しているが、本実施の形態では、５０（％）という中央値からより乖離した値の方を採用する。すなわち、フィールド値に時間に関連する文字以外の文字が含まれている場合の確度スコア５（％）よりも１（％）を採用する。

一方、スキーマ情報が存在しない図９（ａ）の場合には、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２及び３については同様であるが、フィールド４については、当該フィールドのデータ型が特定できないので、フィールド値に時間に関連する文字以外の文字が含まれている場合に該当すると判断され、確度スコア５（％）と特定される。

また、図５（ａ）のようなスキーマ情報で図５（ｂ）のようなレコード群の場合にも、フィールド２乃至４については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。フィールド５については、フィールド名の文字列に「納期」が含まれているので、確度スコア１０（％）と特定される。なお、フィールド５については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ」の形式であるので、タイムスタンプ確度スコア表において複数項目に該当しているが、本実施の形態では、５０（％）という中央値からより乖離した値の方を採用する。すなわち、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ」の形式である場合の確度スコア７０（％）よりも１０（％）を採用する。スキーマ情報が存在しない図１０（ａ）の場合には、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２乃至５については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。

さらに、図６（ａ）のようなスキーマ情報で図６（ｂ）のようなレコード群の場合、フィールド２乃至５については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。スキーマ情報が存在しない図１１（ａ）の場合には、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２乃至５については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。

また、図７（ａ）のようなスキーマ情報で図７（ｂ）のようなレコード群の場合、フィールド２乃至４については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。スキーマ情報が存在しない図１２（ａ）の場合は、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２乃至４については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。

さらに、図８（ａ）のようなスキーマ情報で図８（ｂ）のようなレコード群の場合、フィールド１及び２については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。スキーマ情報が存在しない図１３（ａ）の場合も、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。

図１４の説明に戻って、処理対象フィールドのタイムスタンプ判定を特定された確度スコアに設定する（ステップＳ４１）。上で述べた数値が特定される。

そして、処理対象テーブルにおいて全てのフィールドについて処理したか判断する（ステップＳ４３）。未処理のフィールドが存在する場合にはステップＳ３１に戻る。一方、全てのフィールドを処理した場合には元の処理に戻る。

このように、イベントのタイムスタンプとして蓋然性の高いフィールドに高い値の確度スコアが設定される。また、データ型からタイムスタンプであることが明らかであれば「確定」という蓋然性を表すデータが設定される。

図３の説明に戻って、次に、イベント候補データ生成部３のイベントＩＤ・関連ＩＤ候補処理部３２は、イベントＩＤ及び関連ＩＤ候補判定処理を実施する（ステップＳ９）。このイベントＩＤ及び関連ＩＤ候補判定処理については、図１６及び図１７を用いて説明する。

イベントＩＤ・関連ＩＤ候補処理部３２は、分析対象データ格納部１に格納されている解析対象テーブルのうち未処理のフィールドを１つ特定する（ステップＳ５１）。そして、分析対象データ格納部１に格納されている、処理対象フィールドのフィールド値が、全レコードで一意となっているか判断する（ステップＳ５３）。処理対象フィールドのフィールド値が、全レコードで一意となっていない、すなわち値が重複しているレコードが存在する場合には、ステップＳ６２に移行する。

イベントＩＤはイベントの識別子の格納フィールドであるので、そのフィールド値が互いに重複することはない。したがって、処理対象フィールドに重複する値が存在すれば、それはイベントＩＤではないと判断できる。

一方、処理対象フィールドのフィールド値が、全レコードで一意である場合には、分析対象データ格納部１に格納されている、処理対象フィールドのフィールド値にＮＵＬＬが含まれているか判断する（ステップＳ５５）。処理対象フィールドのフィールド値にＮＵＬＬが含まれている場合には、ステップＳ６２に移行する。イベントＩＤはイベントの識別子の格納フィールドであるので、そのフィールド値がＮＵＬＬということはあり得ないためである。処理対象フィールドのフィールド値が全レコードで一意とは言えない場合、又は処理対象フィールドのフィールド値にＮＵＬＬを含む場合、分析対象データ格納部１に格納されている、処理対象フィールドのフィールド値が、ＮＵＬＬを除いて２以上あるか否か判断する（ステップＳ６２）。処理対象フィールドのフィールド値が、ＮＵＬＬを除いて２種類以上ない場合には、イベントＩＤ・関連ＩＤ候補判定に「否定」を設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ６３）。そして処理はステップＳ６１に移行する。関連ＩＤはあるイベントが他のイベントのどれに対応しているかを表す値であるので、そのフィールド値がＮＵＬＬを除き２以上の値を有しない場合は、意味がある結果が得られないためである。

例えば図４（ｂ）や図９（ｂ）のようなテーブルの場合、フィールド１とフィールド２とフィールド４とについては、フィールド値に重複が存在せず、フィールド３ついてはフィールド値に重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。

また図５（ｂ）や図１０（ｂ）のようなテーブルの場合、フィールド１とフィールド２については、フィールド値に重複が存在せず、フィールド３乃至５については重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。

さらに図６（ｂ）や図１１（ｂ）のようなテーブルの場合、フィールド１とフィールド２については、フィールド値に重複が存在せず、フィールド３乃至５については重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。

また図７（ｂ）や図１２（ｂ）のようなテーブルの場合、フィールド１とフィールド２については、フィールド値に重複が存在せず、フィールド３及び４については重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。

さらに図８（ｂ）や図１３（ｂ）のようなテーブルの場合、フィールド１とフィールド２について、フィールド値に重複が存在しないので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。

ステップＳ５５において処理対象フィールドのフィールド値にＮＵＬＬが含まれていないと判断された場合、又はステップＳ６２において処理対象フィールドのフィールド値が、ＮＵＬＬを除いて２種類以上値を有すると判断された場合には、スコア表格納部３５に格納されているイベントＩＤ・関連ＩＤ候補確度スコア表に従って、スキーマ情報における処理対象フィールドの該当データ部分、処理対象フィールドのフィールド名を表すラベルデータ、及び処理対象フィールドのフィールド値から確度を特定する（ステップＳ５７）。但し、イベントＩＤ・関連ＩＤ候補確度スコア表に該当項目が存在しない場合には、確度スコア５０（％）が特定されるものとする。

イベントＩＤ・関連ＩＤ候補確度スコア表の一例を図１７に示す。図１７の例では、フィールドのデータ型が可変長文字列であれば確度スコアは１（％）と設定され、フィールドのデータ型が実数であれば確度スコアは５（％）と設定され、フィールドのデータ型が整数であれば確度スコアは８０（％）と設定され、フィールドのデータ型が固定長文字列であれば確度スコアは７０（％）と設定され、フィールドのデータ型がタイムスタンプ又は日付であれば確度スコアは１０（％）と設定され、フィールド名が主キー指定されていれば確度スコアは８０（％）と設定される。フィールド値又はフィールド名の文字列についての項目はここでは定義されていないが、定義されることもある。フィールド値についての項目が定義される場合にはステップＳ５７で参照される。

例えば図４（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３についてはデータ型が固定長文字列であるので確度スコア７０（％）と特定され、フィールド４についてはデータ型が可変長文字列であるので確度スコア１（％）と特定される。図９（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１乃至フィールド４について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。

例えば図５（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３及びフィールド４についてはデータ型が固定長文字列であるので確度スコア７０（％）が特定され、フィールド５についてはデータ型が日付となっているので確度スコア１０（％）が特定される。図１０（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１乃至５について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。

例えば図６（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３乃至フィールド５についてはデータ型が固定長文字列であるので確度スコア７０（％）が特定される。図１１（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１乃至５について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。

例えば図７（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３及びフィールド４についてはデータ型が固定長文字列であるので確度スコア７０（％）が特定される。図１２（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１乃至４について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。

例えば図８（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド２についてはデータ型が固定長文字列であるので確度スコア７０（％）が採用される。図１３（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１及び２について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。

そして、イベントＩＤ・関連ＩＤ候補処理部３２は、イベントＩＤ・関連ＩＤ候補判定に、ステップＳ５７で特定された確度スコアを設定して、例えばメインメモリなどの記憶装置に格納する（ステップＳ５９）。

その後、処理対象テーブルにおいて全てのフィールドについて処理したか判断し（ステップＳ６１）、未処理のフィールドが存在する場合にはステップＳ５１に戻る。一方、全てのフィールドについて処理した場合には元の処理に戻る。

このようにすれば、イベントＩＤ又は関連ＩＤの蓋然性が高いものについては高い確度スコアが特定されるようになる。また、イベントＩＤ又は関連ＩＤの可能性が完全にないものについては「否定」という蓋然性を表すデータが特定される。

図３の説明に戻って、次に、イベント候補データ生成部３のイベント名処理部３４は、イベント名判定処理を実施する（ステップＳ１３）。このイベント名判定処理については、図１８乃至図２０を用いて説明する。

まず、イベント名処理部３４は、タイムスタンプ判定処理の処理結果として所定の確度スコア以上でタイムスタンプのフィールドとしてみなすことができるフィールドの数をカウントする（ステップＳ９１）。例えば確度スコア７０（％）以上などの閾値を設定する。当然ながら「確定」と特定されているフィールドはタイムスタンプのフィールドである。上で述べた例では、品番ＤＢを除き、フィールド名が日時であるフィールドがタイムスタンプのフィールドと判断され、フィールド数は「１」となる。品番ＤＢでは、タイムスタンプとみなすことができるフィールドはないので、フィールド数は「０」となる。

そして、タイムスタンプのフィールド数が０であるか否か判断する（ステップＳ９３）。フィールド数が０であれば、解析対象テーブルを以下の処理の対象外として設定する（ステップＳ９５）。タイムスタンプがないテーブル（例えば品番ＤＢ）は、業務プロセス中に発生するイベントに対応しているテーブルではないと判断される。そして元の処理に戻る。

一方、タイムスタンプのフィールド数が０ではない場合には、フィールド数が１であるか否か判断する（ステップＳ９７）。タイムスタンプのフィールド数が１であれば、イベント名にテーブル名を設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ９９）。上の例では、受注ＤＢであれば、イベント名は「受注」と特定され、生産ＤＢであれば、イベント名は「生産」と特定され、手配ＤＢであれば、イベント名は「手配」と特定され、配送ＤＢであれば、イベント名は「配送」と特定される。そして元の処理に戻る。

また、タイムスタンプのフィールド数が複数である場合には、タイムスタンプとみなされたフィールドのフィールド名をイベント名に設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１０１）。そして元の処理に戻る。

例えば図１９のようなテーブルが処理対象テーブルである場合にステップＳ１０１が実行される。図１９の例では、起票日時、承認日時、発注日時、納品日時、検収日時がそれぞれイベントのタイムスタンプとみなされるフィールドとなり、１レコードにイベントが複数記録される形式となっている。このようなテーブルは、図２０（ａ）乃至（ｅ）に示したような起票テーブル、承認テーブル、発注テーブル、納品テーブル及び検収テーブルという複数テーブルとして扱うことができる。従って、このような場合には、「起票」「承認」「発注」「納品」「検収」がそれぞれイベント名として特定される。

以上のような処理を実施することによって、業務プロセス中に発生するイベントに対応しているテーブルを特定すると共に、イベント名を抽出することができるようになる。

図３の説明に戻って、次に、イベント候補データ生成部３は、判定結果を入出力部１１を介してユーザに提示する（ステップＳ１５）。例えば、図４（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の受注ＤＢの場合には、図２１に示すようなデータがユーザに提示される。図２１の例では、日時フィールド、受注番号フィールド、地域フィールド、受注内容フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、受注番号フィールド及び地域フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。

また、図９（ａ）に示したＣＳＶ形式の受注ＤＢの場合には、図２２に示すようなデータがユーザに提示される。図２２の例では、日時フィールド、受注番号フィールド、地域フィールド、受注内容フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。

例えば、図５（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の生産ＤＢの場合には、図２３に示すようなデータがユーザに提示される。図２３の例では、日時フィールド、生産番号フィールド、受注番号フィールド、品番フィールド、納期フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、生産番号フィールドと受注番号フィールドと品番フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。

また、図１０（ａ）に示したＣＳＶ形式の生産ＤＢの場合には、図２４に示すようなデータがユーザに提示される。図２４の例では、日時フィールド、生産番号フィールド、受注番号フィールド、品番フィールド、納期フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。

例えば、図６（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の手配ＤＢの場合には、図２５に示すようなデータがユーザに提示される。図２５の例では、日時フィールド、手配番号フィールド、受注番号フィールド、品番フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、手配番号フィールドと受注番号フィールドと品番フィールドと納品先フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。

また、図１１（ａ）に示したＣＳＶ形式の手配ＤＢの場合には、図２６に示すようなデータがユーザに提示される。図２６の例では、日時フィールド、手配番号フィールド、受注番号フィールド、品番フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。

例えば、図７（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の配送ＤＢの場合には、図２７に示すようなデータがユーザに提示される。図２７の例では、日時フィールド、手配番号フィールド、配送便フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、手配番号フィールドと配送便フィールドと納品先フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。

また、図１２（ａ）に示したＣＳＶ形式の配送ＤＢの場合には、図２８に示すようなデータがユーザに提示される。図２８の例では、日時フィールド、手配番号フィールド、配送便フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。

例えば、図８（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の品番ＤＢの場合には、図２９に示すようなデータがユーザに提示される。図２９の例では、品番フィールド、品名フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、品番ＤＢはタイムスタンプがないと判断され、以降の処理対象外とされているため、イベント名については全て「否定」とされている。これを見れば、タイムスタンプのフィールドが存在する可能性が非常に低く、品番フィールドと品名フィールドはイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。

また、図１３（ａ）に示したＣＳＶ形式の品番ＤＢの場合には、図３０に示すようなデータがユーザに提示される。図３０の例では、品番フィールド、品名フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、品番ＤＢはタイムスタンプがないと判断され、以降の処理対象外とされているため、イベント名については全て「否定」とされている。これを見れば、タイムスタンプのフィールドが存在する可能性は非常に低く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。

図３の説明に戻って、ステップＳ１５が終了すると、ユーザは、入出力部１１を介して、イベント名、タイムスタンプ、イベントＩＤ・関連ＩＤ候補などについて修正入力又は確定入力を行い、レコードのコピーなどを行って又は命じて、イベント候補データを生成し、イベント候補データ生成部３にイベント候補データ格納部５へ格納させる（ステップＳ１６）。この作業は主に又は一部ユーザによって実施されるので、図３では点線ブロックで描かれている。そして処理はステップＳ３に戻る。

例えば図２１の判定結果に従って、図３１に示すようにイベント名についてはテーブル名である「受注」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については受注番号フィールド及び地域フィールドを確定させる場合、例えば図３２に示すようなデータが、イベント候補データ格納部５に格納される。図３２に示す例では、イベント名「受注」が全てのレコードに付加され、日時フィールドのフィールド値の全レコード分がタイムスタンプのフィールドにコピーされ、受注番号フィールド及び地域フィールドがイベントＩＤ・関連ＩＤ候補として、フィールド名とフィールド値の全レコード分がコピーされる。

例えば図２２の判定結果に従って、イベント名についてはテーブル名である「受注」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については受注番号フィールド、地域フィールド及び受注内容フィールドを確定させる場合、例えば図３３のようなデータが、イベント候補データ格納部５に格納される。

さらに例えば図２３の判定結果に従って、イベント名についてはテーブル名である「生産」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については生産番号フィールド、受注番号フィールド及び品番フィールドを確定させる場合、例えば図３４のようなデータが、イベント候補データ格納部５に格納される。

また例えば図２４の判定結果に従って、イベント名についてはテーブル名である「生産」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については生産番号フィールド、受注番号フィールド、品番フィールド及び納期フィールドを確定させる場合、例えば図３５のようなデータが、イベント候補データ格納部５に格納される。

さらに例えば図２５の判定結果に従って、イベント名についてはテーブル名である「手配」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド、受注番号フィールド、品番フィールド及び納品先フィールドを確定させる場合、例えば図３６のようなデータが、イベント候補データ格納部５に格納される。

また例えば図２６の判定結果に従って、イベント名についてはテーブル名である「手配」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド、受注番号フィールド、品番フィールド及び納品先フィールドを確定させる場合、例えば図３７のようなデータが、イベント候補データ格納部５に格納される。

さらに例えば図２７の判定結果に従って、イベント名についてはテーブル名である「配送」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド、配送便フィールド及び納品先フィールドを確定させる場合、例えば図３８のようなデータが、イベント候補データ格納部５に格納される。

また例えば図２８の判定結果に従って、イベント名についてはテーブル名である「配送」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド、配送便フィールド及び納品先フィールドを確定させる場合、例えば図３９のようなデータが、イベント候補データ格納部５に格納される。

また、例えば図１９のようなテーブル内に複数のタイムスタンプのフィールドが存在するようなテーブルを処理対象とする場合は、例えば図４０乃至図４４に示すようなデータが、イベント候補データ格納部５に格納される。図４０乃至図４４に示す例では、タイムスタンプとして確定されたフィールドである起票日時、承認日時、発注日時、納品日時、検収日時を元に、それらのフィールド毎に、各々イベント名を「起票」、「承認」、「発注」、「納品」、「検収」と確定させたイベント候補データを作成する。タイムスタンプについては、起票日時フィールド、承認日時フィールド、発注日時フィールド、納品日時フィールド、検収日時フィールドのフィールド値の全レコード分が各々のイベント候補データのタイムスタンプのフィールドにコピーされる。さらに、全てのイベント候補データ共通に、起票日時フィールド、承認日時フィールド、発注日時フィールド、納品日時フィールド、検収日時フィールド以外のフィールドについては、イベントＩＤ・関連ＩＤ候補として、フィールド名とフィールド値の全レコード分がコピーされる。

このようにして以下の処理で用いるイベント候補データがイベント候補データ格納部５に格納されるようになる。

図３の説明に戻って、ステップＳ３で全ての解析対象テーブルを処理したと判断された場合には、イベントデータ生成部７は、イベント候補データ格納部５に格納されているイベント候補データを用いて、イベントデータ生成処理を実施し、処理結果をイベントデータ格納部９に格納する（ステップＳ１７）。

受注イベント、生産イベント、手配イベント、配送イベントに対応して、各々、図３２、図３４、図３６、図３８に示されたイベント候補データのセット、または、各々、図３３、図３５、図３７、図３９に示されたイベント候補データのセットを用いて生成したイベントデータの例を図４５に示す。その生成方法としては、上で述べた特開２００８−２７０７２号公報記載のようなイベントデータの関連情報の自動抽出方式を用いても良いし、人手によって、各イベント候補データのイベントＩＤ・関連ＩＤ候補のフィールド値の対応関係を調査・分析することによって、イベント間の関連性を確定しても良い。

図４５では、受注イベントのイベントＩＤは受注番号であり、生産イベントのイベントＩＤは生産番号、関連ＩＤは受注番号であり、手配イベントのイベントＩＤは手配番号、関連ＩＤは受注番号であり、配送イベントのイベントＩＤは手配番号、関連ＩＤは配送便であることが確定されている。また、生産イベントの関連ＩＤのフィールド値が、受注イベントのイベントＩＤのフィールド値のどれかの値をとることにより、生産イベントの各々のレコード（すなわち、イベントインスタンス）が、受注イベントのどのレコード（すなわち、イベントインスタンス）と関連しているかが特定されるというイベント間の関連性が確定されている。同様の関連性が、手配イベントの関連ＩＤと受注イベントのイベントＩＤとの間、配送イベントのイベントＩＤと手配イベントのイベントＩＤとの間に確定されている。

また、プロセスインスタンス生成部１３は、イベントデータ格納部９に格納されているイベントデータを用いてプロセスインスタンス生成処理を実施し、処理結果をプロセスインスタンスデータ格納部１５に格納する（ステップＳ１９）。その生成方法としては、米国特許公開公報２００５／０７６０５９Ａ１のような業務プロセストラッキング方法等を用いることができる。

図４５のイベントデータを用いて、受注番号：ＪＴ０１の受注イベントインスタンスを起点とするプロセスインスタンスを生成する処理過程の概略説明を図４６に示す。最初に、関連ＩＤのフィールド値が、受注イベントのイベントＩＤである受注番号のフィールド値：ＪＴ０１をとるレコード（すなわち、イベントインスタンス）として、生産イベントから２つ、手配イベントから３つのイベントインスタンスが確定される。次に、確定された手配イベントのイベントＩＤである手配番号：ＴＨ０１，ＴＨ０２，ＴＨ０３を関連ＩＤのフィールド値としてとるレコード（すなわち、イベントインスタンス）として、配送イベントから３つのイベントインスタンスが確定される。最後に、確定された、受注番号：ＪＴ０１の受注イベントインスタンスを起点として、直接・間接的に関連性をもつイベントインスタンスを、そのタイムスタンプの値に基づいて時間経過の順につなぎ合わせることによって、プロセスインスタンスが生成される。すなわち、第１のプロセスインスタンスとしては、イベントクラスが、受注、生産、手配、手配、手配、配送、生産、配送、配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスが生成される。

同様にして、図４５のイベントデータを用いて生成した全プロセスインスタンスを図４７に示す。第２のプロセスインスタンスは、イベントクラスが、受注、手配及び配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスである。第３のプロセスインスタンスは、イベントクラスが、受注、生産、生産、手配及び配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスである。さらに、第４のプロセスインスタンスは、イベントクラスが、受注、手配及び配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスである。

図３の処理フローの説明に戻って、次に、並列処理推定部１７は、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスのデータを用いて、並列処理推定処理を実施する（ステップＳ２１）。この処理については、図４８乃至図７４を用いて詳細に説明する。

まず、図４８乃至図５６−２を用いて並列処理推定処理を実施する趣旨について説明する。まず、図４８に示すように、プロセスインスタンスデータ格納部１５に１０個のプロセスインスタンスが格納されているものとする。それらのプロセスインスタンスを構成する各々のイベントインスタンスが属するイベントクラスの並び方に基づいて、プロセスインスタンスを分類し、グループ化し、メンバのプロセスインスタンスの数が多い順に並べると次のようになる。このような処理はプロセスインスタンス分類処理部２１で実施される。先ず、イベントクラスの並び方がInitial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateであるプロセスインスタンスが５つでグループＡが構成される。また、Initial State、契約、伝票作成、請求及び回収の後に契約更新を介して伝票作成に戻って請求及び回収の後、さらに契約満了及びFinal Stateが発生するプロセスインスタンスが３つでグループＢが構成される。さらに、Initial State、契約、伝票作成、請求及び回収の後に継続を介して請求に戻って、回収、契約満了及びFinal Stateが発生するプロセスインスタンスが１つでグループＣが構成される。そして、Initial State、契約、伝票作成、請求の後、回収、回収と繰り返した後、契約満了及びFinal Stateが発生するプロセスインスタンスが１つでグループＤが構成される。ただし、Initial State及びFinal Stateは、各プロセスインスタンスの先頭・末尾に付けられる仮想的なイベントクラスである。

このようなグループＡ乃至Ｄのプロセスインスタンスのグループをプロセス表示処理部２５により重ね合わせ表示すると、図４９に示すような全体フローが表示される。この表示では、各イベントクラスを示す楕円を各１個のみ表示し、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため１本のみとしている。

また、例えばグループの出現頻度の全体に対して占める比率２０％を閾値として、主要フローと例外フローとに分ける場合には、図５０（ａ）に示すように、主要フローとしては、グループＡとグループＢのプロセスインスタンスが重ね合わされたフローが生成され、ユーザに提示される。この表示では、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため１本のみとしている。これに対して、例外フローは、図５０（ｂ）に示すグループＣのプロセスインスタンス、図５０（ｃ）に示すグループＤのプロセスインスタンスがユーザに提示される。

図４８に示したプロセスインスタンスの場合には、主要フローと例外フローに分ける上で問題はあまりなく、ユーザは、図４９や図５０に示したような図で、業務フローの概況を容易に把握できるようになる。グループＡだけでも５０％の出現頻度を占めるため、グループＡのみを主要フローとして認めても、図５０と同様に、業務フローの概況を把握する上で特別に問題はない。

一方、図５６に示すように、実際の業務に並列処理の部分が存在する業務フロー（図５４）を持つシステムから得られたデータに対して、ステップＳ１乃至Ｓ１９までの処理を行うと、図５１に示すように、実際の業務には存在しない見かけ上遷移を構成要素として含むプロセスインスタンスが生成される。その理由は、互いのＩＤに関連性が有るイベント同士を単純に時系列に繋ぐため、図５４の並列処理を含む業務フローでは、互いに並列関係にある部分フロー中のイベント間に見かけ上の遷移を誤設定するためである。

図５４に示す並列処理を含む業務フローは、Initial State、契約というイベントクラスが並んでいる部分フローの後に、伝票作成、請求、回収というイベントクラスが並んでいる部分フローと、継続及び契約更新というイベントクラスが並んでいる部分フローとが、互いに並列の関係で続き、その後に、契約満了、Final Stateというイベントクラスが並んでいる部分フローに合流している。分析対象の業務システム・業務フローに、このような互いに並列関係にある部分フローを含むことが既知である場合には、それらの並列関係を反映したデータの前処理、例えば、互いに並列関係にある部分フローのうち１つのみを残して他の部分フローを構成するイベントクラスのデータを削除する処理などを行う必要がある。

しかし、分析対象の業務システム・業務フロー中の並列処理の存在や、どのような並列処理が存在するかについての十分な情報がなく、データの前処理を行えずに、ステップＳ１乃至Ｓ１９までの処理を行わざるを得ない場合がある。その場合には、図５１に示すようなプロセスインスタンスが生成される。具体的には、Initial State、契約、伝票作成、請求、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいる基本的なプロセスインスタンスが４つ存在しており、グループＦを構成している。一方、上で述べたように、互いに並列関係にある、伝票作成、請求、回収というイベントクラスが並んでいる部分フローと、継続及び契約更新というイベントクラスが並んでいる部分フローの構成要素のイベントインスタンス同士間に、実際の業務フローとは関係ない見かけ上遷移を設定してしまった、Ａ乃至Ｅのような１つのプロセスインスタンスで構成されるグループが得られてしまう。グループＡには、Initial State、契約、「伝票作成、継続、請求、契約更新、回収」、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。グループＢには、Initial State、契約、伝票作成、「請求、継続、回収、契約更新」、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。さらに、グループＣには、Initial State、契約、伝票作成、請求、「回収、継続」、契約更新、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。また、グループＤには、Initial State、契約、継続、「契約更新、伝票作成」、請求、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。さらに、グループＥには、Initial State、契約、「継続、伝票作成、契約更新、請求」、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。このように「」で示したイベントインスタンス間の遷移が見かけ上遷移である。図７３に、それらの見かけ上遷移を点線で表示して示す。なお、図５１には、グループＡ乃至Ｅとは別に、Initial State、契約、伝票作成、請求、請求、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを１つ含むグループＧも存在する。グループＧでは、請求というイベントクラスに属するイベントインスタンスが繰り返されている。

このような全プロセスインスタンスを単純に重ね合わせると図５２に示すような業務フローが得られる。図５２を見れば分かるように、業務フロー全体を把握するには煩雑すぎる。また、上で述べたのと同様に閾値２０％で主要フローと例外フローとを分けると、図５３に示すようになる。すなわち、グループＦは全体の４０％で主要フローと判断されるが、グループＡ乃至Ｅ及びＧについては全て１０％であるから例外フローと判断される。しかしながら、実はグループＡ乃至Ｅは、図５４に示すような並列処理を含む業務フローから生成されたイベントインスタンスを、単純に日時の順番に連結してしまったために見かけ上遷移を構成要素とするプロセスインスタンスとして生成されたものである。すなわち、本来、生成されるべきプロセスインスタンスは、契約、伝票作成、請求、回収、契約満了という順番でイベントインスタンスが発生する主要経路と、契約から分岐して継続及び契約更新と続き契約満了に遷移する並列経路とを含むプロセスインスタンスである。

グループＡ乃至Ｅを、図５４−２に示すような本来の並列経路を含むプロセスインスタンスに修正すると、図５５に示すように、これら（グループＡＥ）は全体の５０％を占めるようになるため、これらが第１の主要フローとなり、グループＦは第２の主要フローとなる。従って、例外フローはグループＧのみとなる。全プロセスインスタンスを重ね合わせたとしても、図５６−２に示すように、図５２と比べて格段に整理され、把握のしやすい業務フローをユーザに提示できるようになる。

そこで、図５７乃至図７４に示すような処理を実施することによって、従来技術で生成したプロセスインスタンスにおいて見かけ上の遷移であって実際の業務上は遷移が発生している可能性が低いものを検出し、業務フローにおける並列処理の存在を推定することによって、ユーザが本来の業務フローの概要を把握できるようにする。

並列処理推定部１７の統計情報抽出部１７１は、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスからイベント間遷移頻度表を生成し、統計情報格納部１７３に格納する（図５７：ステップＳ１１１）。発側イベントクラスと着側イベントクラスとの各組み合わせについて、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスにおける、該当発側イベントインスタンスと該当着側イベントインスタンスの組み合わせについてのイベント間遷移の発生頻度をカウントして、イベント間遷移頻度表に登録する。図５８に模式的に示すように、例えば発側イベントクラスとして「請求」と着側イベントクラスとして「回収」との組み合わせに着目すると、点線で囲まれた部分がカウントされる。すなわち、プロセスインスタンスＣ、Ｄ、Ｅ及びＧで１回、プロセスインスタンスＦで４回カウントされるので、合計８回となる。よって図５８の下段テーブルに示すように、発側イベントクラス「請求」と着側イベントクラス「回収」の対応セルに「８」が登録される。このような処理を全てのイベントクラスの組み合わせについて実施すれば、図５９に示すようなイベント間遷移頻度表が生成される。図５９の例では、横方向に着側イベントクラスが列挙され、縦方向に発側イベントクラスが列挙されている。ただし、Initial State及びFinal Stateは、各プロセスインスタンスの先頭・末尾に付けられる仮想的なイベントクラスであり、Initial Stateに到着するイベント間遷移及び、Final Stateから出発するイベント間遷移は存在しないので、それらに対応するセルには「−」が記載されている。

次に、統計情報抽出部１７１は、統計情報格納部１７３に格納されているイベント間遷移頻度表から、各イベントの発生確率及び条件付き確率の近似値を算出し、統計情報格納部１７３に格納する（ステップＳ１１３）。本ステップでは、図６０に示すように、各発側イベントＸを固定し、着側イベント全てとの組み合わせについてイベント間遷移頻度Ｆ（Ｙ｜Ｘ）の総和をとることで、各イベントクラスＸに属するイベントインスタンスの発生頻度Ｔ（Ｘ）を計算する。以下、記述の煩雑を避けるため、各イベントクラスＸに属するイベントインスタンスの発生頻度を、各イベントＸの発生頻度と略する。なお、本実施の形態で取り扱う各プロセスインスタンスの先頭・末尾に付けられる仮想的なイベントクラスであるInitial State 及びFinal Stateを有するような状態遷移頻度表の場合には、着側のイベントＹを固定し、発側イベント全てとの組み合わせについて頻度Ｆ（Ｙ｜Ｘ）の総和をとることによって、各イベントＹの発生頻度Ｔ（Ｙ）を算出しても同じ値が得られる。次に、イベント全部の発生頻度の和ＧＴを算出する。さらに、全てのプロセスインスタンスに含まれ、イベントクラスＸに属するイベントインスタンスの数を直接カウントすることで、各イベントＸの発生頻度Ｔ（Ｘ）を求めるようにしても良い。次に、全イベントクラスについて、Ｔ（Ｘ）の和を計算することで、総イベント発生頻度ＧＴを算出する。なお、総イベント発生数ＧＴは、全てのプロセスインスタンスに含まれ、仮想的なイベントクラスであるInitial State 及びFinal State以外のイベントクラスに属するイベントインスタンスの数を直接カウントすることで、求めるようにしても良い。

そして、図６１に示すように、各イベントクラスＸに属するイベントインスタンスの発生確率の近似値をＰ（Ｘ）≒Ｔ（Ｘ）／ＧＴとして算出して、統計情報格納部１７３に格納する。以下、記述の煩雑をさけるため、各イベントクラスＸに属するイベントインスタンスの発生確率を、各イベントＸの発生確率と略する。同様にして、図６２に示すように、発側イベントＸが発生した場合に着側イベントＹが発生する条件付き確率Ｐ（Ｙ｜Ｘ）の近似値を、Ｐ（Ｙ｜Ｘ）≒Ｆ（Ｙ｜Ｘ）／Ｔ（Ｘ）として算出して、統計情報格納部１７３に格納する。以下、記述の煩雑をさけるため、発側イベントＸが発生した場合に着側イベントＹが発生する条件付き確率を、曖昧とならない場合は適宜、条件付き確率と略する。

図５９の例を基にイベントの発生確率Ｐ（Ｘ）の近似値を算出すると、図６３に示すようなデータが統計情報格納部１７３に格納される。また、同じく図５９の例を基に条件付き確率Ｐ（Ｙ｜Ｘ）の近似値を算出すると、図６４に示すようなデータが統計情報格納部１７３に格納される。

次に、統計情報抽出部１７１は、統計情報格納部１７３に格納されている各イベントの発生確率及び条件付き確率に基づき、各遷移について見かけ上遷移の評価指標値を算出し、統計情報格納部１７３に格納する（ステップＳ１１５）。上でも述べたが、見かけ上遷移とは、業務システムから得られたデータに対して、ステップＳ１乃至Ｓ１９までの処理を機械的に適用し、イベントＩＤを共有または、関連ＩＤを介して対応関係のあるイベントインスタンス（のレコード）を、単純に発生日時に基づき直列的に接続することで作成したプロセスインスタンスを構成する遷移だが、実際の業務上は存在しない遷移である。

見かけ上遷移検出評価指標値は、以下の統計的な性質を用いて定義される。先ず、事象Ａが発生する場合に事象Ｂが発生する条件付き確率Ｐ（Ｂ｜Ａ）は、事象Ａが発生し、かつ、事象Ｂが発生する確率Ｐ（Ａ∩Ｂ）に対して、等式Ｐ（Ａ∩Ｂ）＝Ｐ（Ｂ｜Ａ）Ｐ（Ａ）を成り立たせるものとして定義される。一方、図６５に示すように、事象Ａと事象Ｂとが独立に発生する場合には、事象Ａと事象Ｂとに重複する部分は存在しない。すなわち、事象Ａと事象Ｂとが独立事象である必要十分条件は、ＡとＢとが同時に発生する確率Ｐ（Ａ∩Ｂ）は、事象Ａが発生する確率Ｐ（Ａ）と事象Ｂが発生する確率Ｐ（Ｂ）について、Ｐ（Ａ∩Ｂ）＝Ｐ（Ａ）Ｐ（Ｂ）が成り立つことである。したがって、事象Ａと事象Ｂとが独立に発生する場合には、事象Ａが発生する場合に事象Ｂが発生する条件付き確率Ｐ（Ｂ｜Ａ）については、Ｐ（Ｂ｜Ａ）＝Ｐ（Ｂ）が導出される。同様に、事象Ｂが発生する場合に事象Ａが発生する条件付き確率Ｐ（Ａ｜Ｂ）についても、Ｐ（Ａ｜Ｂ）＝Ｐ（Ａ）が導出される。

プロセスインスタンスに主要経路と分岐した並列経路とが含まれている場合、すなわち、並列処理を含む業務フローから発生したプロセスインスタンスの場合、主要経路中のイベントクラスのイベントインスタンスと、並列経路中のイベントクラスのイベントインスタンスとは、互いに業務上無関係であるので、独立に発生するとみなすことができる。従って、見かけ上遷移の条件付き確率Ｐ（見かけ上遷移の着側イベント｜見かけ上遷移の発側イベント）と、見かけ上遷移の着側イベントのイベントクラスに属するイベントインスタンスの発生確率Ｐ（見かけ上遷移の着側イベント）について、Ｐ（見かけ上遷移の着側イベント｜見かけ上遷移の発側イベント）＝Ｐ（見かけ上遷移の着側イベント）が成立する。

すなわち、｜１−Ｐ（見かけ上遷移の着側イベント｜見かけ上遷移の発側イベント）／Ｐ（見かけ上遷移の着側イベント）｜＝０が導出される。従って、本実施の形態における見かけ上遷移の評価指標式としては、｜１−Ｐ（判断対象遷移の着側イベント｜判断対象遷移の発側イベント）／Ｐ（判断対象遷移の着側イベント）｜を採用する。さらに、閾値としては、例えば「１」を採用する。但し、実験的に最適値を求めてその値を用いるようにしても良い。さらに、同様の趣旨に従って定義される他の評価式を採用するようにしても良い。

図６３及び図６４から見かけ上遷移評価指標値を算出すると、図６６に示すような値が得られる。発側イベントと着側イベントが同一の場合には、手戻りを示しており、並列処理とは関係ないので、「−」で示すように評価指標値を算出しない。そうすると、ハッチングが付されているセルに対応する遷移が、評価指標値が「１」未満となる。すなわち、伝票作成から契約更新への遷移、伝票作成から継続への遷移、請求から契約更新への遷移、請求から継続への遷移、回収から契約更新への遷移、回収から継続への遷移、契約更新から伝票作成への遷移、契約更新から請求への遷移、契約更新から回収への遷移、継続から伝票作成への遷移、継続から請求への遷移及び継続から回収への遷移が、評価指標値が閾値未満となっている。

図５７の処理の説明に戻って、見かけ上遷移検出部１７５は、統計情報格納部１７３に格納されている評価指標値が閾値以下である遷移を見かけ上遷移（具体的には、発イベントクラス及び着イベントクラスの組）として検出し、見かけ上遷移削除部１７７及び代替遷移決定処理部１７９に出力する（ステップＳ１１７）。端子Ａを介して図６７の処理に移行する。

図６７の処理の説明に移行して、見かけ上遷移削除部１７７は、プロセスインスタンスデータ格納部１５において未処理のプロセスインスタンスを１つ特定する（ステップＳ１１９）。そして、見かけ上遷移削除部１７７は、見かけ上遷移検出部１７５から受け取った見かけ上遷移のうち未処理の遷移を１つ特定する（ステップＳ１２１）。そして、見かけ上遷移削除部１７７は、特定されたプロセスインスタンスが、特定された見かけ上遷移を含むか確認する（ステップＳ１２３）。図６６のような評価指標値が計算された場合には、ハッチングが付された１２種類の遷移が見かけ上遷移として検出されるので、見かけ上遷移のうちいずれか１つでも含むプロセスインスタンスを抽出する。特定されたプロセスインスタンスが、特定された見かけ上遷移を含まない場合には、見かけ上遷移削除部１７７は、全ての見かけ上遷移について処理したか判断する（ステップＳ１２５）。ここで未処理の見かけ上遷移が存在する場合にはステップＳ１２１に戻る。

一方、全ての見かけ上遷移について処理したが、特定されたプロセスインスタンスに見かけ上遷移が検出されなかった場合には、見かけ上遷移削除部１７７は、特定されたプロセスインスタンスのデータを、並列処理推定後プロセスインスタンスデータ格納部１９に格納する（ステップＳ１２７）。そしてステップＳ１３５に移行する。見かけ上遷移を含んでいない、すなわち、並列処理を含んでいないと判断されたプロセスインスタンスについては、ステップＳ２３以降の処理のために並列処理推定後プロセスインスタンス格納部１９に格納する。

これに対して、特定されたプロセスインスタンスに、特定された見かけ上遷移が含まれている場合には、見かけ上遷移削除部１７７は、特定されたプロセスインスタンスのデータを、並列処理該当プロセスインスタンスデータ格納部１８１に格納する（ステップＳ１２９）。そして、見かけ上遷移削除部１７７は、特定されたプロセスインスタンスにおいて、特定された見かけ上遷移を削除する（ステップＳ１３１）。例えば、図５１のプロセスインスタンスＡをステップＳ１１９で特定した場合には、プロセスインスタンスＡにおいて、見かけ上遷移として検出された遷移に該当する遷移（伝票作成から継続への遷移、継続から請求への遷移、請求から契約更新への遷移、契約更新から回収への遷移）のうちいずれかがステップＳ１３１で削除される。図６８では、既に全ての見かけ上遷移が削除されているが、例えば、伝票作成に対応するデータブロックから継続に対応するデータブロックへの接続を表すポインタが削除される。

さらに、見かけ上遷移削除部１７７は、特定されたプロセスインスタンスに、残余の見かけ上遷移が含まれるか否かを判断し、含まれている場合には該当する遷移を削除する（ステップＳ１３３）。例えば、ステップＳ１２１でまだ特定されていない未処理の見かけ上遷移の各々について、特定されたプロセスインスタンスに含まれるか否かを判断し、含まれていれば、該当する全ての遷移を削除する。プロセスインスタンスＡの場合には、図６８に示すように、×印が付されている遷移のためのポインタが削除される。その後ステップＳ１３５に移行する。

ステップＳ１３５では、見かけ上遷移削除部１７７は、プロセスインスタンスデータ格納部１５における全てのプロセスインスタンスについて処理したか判断する。未処理のプロセスインスタンスが存在する場合にはステップＳ１１９に戻る。一方、全てのプロセスインスタンスを処理した場合には、端子Ｂを介して図６９の処理に移行する。

図６９の処理の説明に移行して、代替遷移決定処理部１７９は、並列処理該当プロセスインスタンスデータ格納部１８１において未処理の抽出プロセスインスタンスを１つ特定する（ステップＳ１３７）。そして、代替遷移決定処理部１７９は、特定された抽出プロセスインスタンスにおいて少なくとも一端が未接続のイベントインスタンスのうち未処理のイベントインスタンスを１つ特定する（ステップＳ１３９）。図６８の例で、例えば継続が特定されるものとする。

そして、代替遷移決定処理部１７９は、特定されたイベントインスタンスの前方（時間的に前）が未接続であるか判断する（ステップＳ１４１）。特定されたイベントインスタンスの前方は接続されている場合にはステップＳ１５７に移行する。一方、特定されたイベントインスタンスの前方が未接続の場合、代替遷移決定処理部１７９は、接続先を探すためのポインタｎを２に初期化する（ステップＳ１４５）。ｎ＝１は図６７の処理で削除されている遷移なのでｎ＝２からスタートする。そして、代替遷移決定処理部１７９は、ｎ個前のイベントが存在するか判断する（ステップＳ１４７）。ｎ個前のイベントが存在しない場合、特定されたイベントインスタンスについて前方に接続できるイベントインスタンスが存在しないということなので、代替遷移決定処理部１７９は、「Initial State」から本イベントインスタンスへの遷移を設定する（ステップＳ１５５）。「Initial State」については仮想的なイベントなので、図６８に示すように、それ自体のデータを保持しない場合もある。保持する場合には、「Initial State」のデータブロックにおいて遷移先を表すポインタに、本イベントインスタンスについてのデータブロックのアドレスを追加する。一方、図６８に示すように保持していない場合には、本イベントインスタンスについてのデータブロックに、遷移元を表すデータとして「Initial State」を表すデータを追加する。処理はステップＳ１５７に移行する。

一方、ｎ個前のイベントインスタンスが存在する場合には、代替遷移決定処理部１７９は、ｎ個前のイベントインスタンスから、特定されたイベントインスタンスへの遷移が、見かけ上遷移に該当するか確認する（ステップＳ１４９）。プロセスインスタンスＡであれば、特定されたイベントインスタンスが「継続」であれば、２個前のイベントインスタンスは「契約」というイベントクラスのイベントインスタンスであるから、見かけ上遷移に該当しない。ｎ個前のイベントインスタンスから処理に係るイベントインスタンスへの遷移が見かけ上遷移に該当しない場合には、代替遷移決定処理部１７９は、ｎ個前のイベントインスタンスから処理に係るイベントインスタンスへの遷移を設定する（ステップＳ１５３）。図６８の「継続」の場合には、図７０に模式的に示すように「契約」についてのデータブロックに「継続」についてのデータブロックへのポインタを追加する。処理はステップＳ１５７に移行する。

一方、図７１に示すように、プロセスインスタンスＢの「継続」というイベントクラスのイベントインスタンスについて処理する場合、２つ前のイベントインスタンスは「伝票作成」というイベントクラスのイベントインスタンスであって、「伝票作成」から「継続」への遷移が見かけ上遷移に該当するため選択できない。

すなわち、ｎ個前のイベントインスタンスから処理に係るイベントインスタンスへの遷移が見かけ上遷移に該当する場合には、代替遷移決定処理部１７９は、ｎを１インクリメントして（ステップＳ１５１）、ステップＳ１４７に戻る。

図７１の例では、３つ前のイベントインスタンスは「契約」というイベントクラスのイベントインスタンスであって、「契約」から「継続」への遷移が見かけ上遷移に該当しないので、「契約」についてのデータブロックに「継続」についてのデータブロックへのポインタを追加する。

ステップＳ１５７では、代替遷移決定処理部１７９は、特定されたイベントインスタンスの後方（時間的に後ろ）が未接続であるか判断する。既に遷移が確定している場合には端子Ｃを介して図７２のステップＳ１７１に移行する。一方、特定されたイベントインスタンスの後方が未接続である場合には端子Ｄを介して図７２のステップＳ１５９に移行する。

図７２の処理の説明に移行して、代替遷移決定処理部１７９は、ｎを２に初期化し（ステップＳ１５９）、特定された抽出プロセスインスタンスにおいて、ｎ個後のイベントインスタンスが存在するか判断する（ステップＳ１６１）。ｎ個後のイベントが存在しない場合、特定されたイベントインスタンスについて後方に接続できるイベントインスタンスが存在しないということなので、代替遷移決定処理部１７９は、本イベントインスタンスから「Final State」への遷移を設定する（ステップＳ１６３）。「Final State」については仮想的なイベントなので、図６８に示すように、それ自体のデータを保持しない場合もある。保持する場合には、本イベントインスタンスについてのデータブロックに、「Final State」についてのデータブロックのアドレスを遷移先を表すポインタとして追加する。一方、図６８に示すように保持していない場合には、本イベントインスタンスについてのデータブロックに、遷移先を表すデータとして「Final State」を表すデータを追加する。処理はステップＳ１７１に移行する。

一方、ｎ個後のイベントインスタンスが存在する場合には、代替遷移決定処理部１７９は、特定されたイベントインスタンスからｎ個後のイベントインスタンスへの遷移が、見かけ上遷移に該当するか確認する（ステップＳ１６５）。プロセスインスタンスＡ及びＢにおいて、特定されたイベントインスタンスが「継続」であれば、２個後のイベントインスタンスは「契約更新」というイベントクラスのイベントインスタンスであるから、見かけ上遷移に該当しない。特定されたプロセスインスタンスからｎ個後のイベントインスタンスへの遷移が見かけ上遷移に該当しない場合には、代替遷移決定処理部１７９は、特定されたプロセスインスタンスからｎ個後のイベントインスタンスへの遷移を設定する（ステップＳ１６９）。図７０及び図７１の「継続」の場合には、「継続」についてのデータブロックに「契約更新」についてのデータブロックへのポインタを追加する。処理はステップＳ１７１に移行する。

一方、特定されたイベントインスタンスからｎ個後のイベントインスタンスへの遷移が見かけ上遷移に該当する場合には、代替遷移決定処理部１７９は、ｎを１インクリメントして（ステップＳ１６７）、ステップＳ１６１に戻る。

ステップＳ１７１では、代替遷移決定処理部１７９は、少なくとも一端が未接続となっている全てのイベントインスタンスについて処理したか判断する。未処理のイベントインスタンスが存在する場合には、端子Ｅを介して図６９のステップＳ１３９に戻る。一方、少なくとも一端が未接続となっている全てのイベントインスタンスについて処理した場合には、並列処理該当プロセスインスタンスデータ格納部１８１に格納されている全ての抽出プロセスインスタンスについて処理したか判断する（ステップＳ１７３）。未処理の抽出プロセスインスタンスが存在する場合には端子Ｆを介して図６９のステップＳ１３７に戻る。全ての抽出プロセスインスタンスについて処理した場合には、代替遷移決定処理部１７９は、並列処理該当プロセスインスタンスデータ格納部１８１に格納されているプロセスインスタンスのデータを、並列処理推定後プロセスインスタンスデータ格納部１９に移動させる（ステップＳ１７５）。

このような処理を行うと、プロセスインスタンスＡ乃至Ｅにおいては、図７３において点線で示すように、本来の遷移ではなく見かけ上遷移に該当すると統計的に判断された遷移については切断され、その切断された遷移の両端のイベントインスタンスについて、切断された側で最も時間的に近くに発生し、かつ、当該イベントインスタンスとの間の遷移が、見かけ上遷移に該当しない遷移であるイベントインスタンスを探し、当該イベントインスタンスと探しだしたイベントインスタンス間の遷移を新たな遷移として設定すると、図７４に示すようなプロセスインスタンスＡ乃至Ｅが得られるようになる。

なお、新たに生成した遷移については、イベントインスタンスの列とはずれた形で矢印で示しているのでわかりにくいが、結局のところ、プロセスインスタンスＡ乃至Ｅは、図５４に示した業務上の並列処理を含む業務フローと同じ形になっている。

上の説明では、見かけ上遷移の削除及び代替遷移の設定について自動的に実施するような例を示したが、例えば、入出力部１１に対して、該当するプロセスインスタンスと見かけ上遷移を提示し、ユーザに、当該見かけ上遷移を削除しても良いか確認するようにしても良い。この場合、削除が指示されればそれに応じて削除する。さらに、代替遷移の設定についても、ユーザに確認の上設定するようにしても良い。すなわち、代替遷移を上で述べた処理にて特定して提示するようにしても良いし、全く提示せずにユーザにより入力してもらうようにしても良い。

図３の説明に戻って、プロセスインスタンス分類処理部２１は、並列処理推定後プロセスインスタンスデータ格納部１９に格納されているプロセスインスタンスを分類し、分類結果に基づき種類毎に計数して、種類毎に計数値をモデルデータ格納部２３に格納する（ステップＳ２３）。図５５に示されたようなプロセスインスタンスが生成された場合には、ステップＳ２３を実施すると図７５に示すようなデータが、モデルデータ格納部２３に格納される。図７５の例では、上で述べた３つのグループのプロセスインスタンスと、それぞれの計数値が登録されている。なお、主要フローフラグの欄には、この段階では何も登録されない。

そして、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、フロー表示処理を実施する（ステップＳ２５）。フロー表示処理について図７６及び図７７を用いて説明する。

まず、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているプロセスインスタンスのグループを計数値に基づき降順に整列させる（ステップＳ１４１）。そして、各プロセスのグループを主要フローとして扱うための判断基準となる、当該グループのプロセスインスタンスの全体に占める比率の閾値を、ユーザから入力された場合には当該入力値により、ユーザの入力がない場合には予め設定されている値で決定する（ステップＳ１４３）。例えば全体に占める比率の閾値２０％以上のグループを主要フローと分類する場合には、２０％を入力する。但し、予め設定されている値（例えば３０％）をそのまま用いるようにしても良い。

そして、プロセス表示処理部２５は、計数値上位より１つ未選択のプロセスインスタンスを選択する（ステップＳ１４７）。この選択されたプロセスインスタンスを主要フロー（典型フローとも呼ぶ）に指定する（ステップＳ１４９）。具体的には、モデルデータ格納部２３のテーブルにおける主要フローフラグをオンにセットする。そして、全体に対して占める比率を算出し（ステップＳ１５１）、比率≧閾値であるか否か判断する（ステップＳ１５３）。この条件が満たされている場合にはステップＳ１４７に戻る。

例えば、図７５の例では、最初に第１レコードを選択すると、全体に占める比率が５０％となり、閾値が２０％であれば、ステップＳ１４７に戻る。次に、第２レコードを選択すると、全体に占める比率は４０％となり、同様に、ステップＳ１４７に戻る。このように第１レコード及び第２レコードについて主要フローフラグがオンにセットされる。

最後に、第３レコードを選択すると、全体に占める比率が１０％となり、全体に占める比率≧閾値という条件が満たされなくなるので、プロセス表示処理部２５は、元の処理に戻る。このようにすれば、ステップＳ１４７で選択されたプロセスインスタンスのグループ以外のプロセスインスタンスは、主要フローフラグがオンにセットされていないので、例外フローとして特定されたことになる。

図３の説明に戻って、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、入出力部１１を介して処理結果を出力する（ステップＳ２７）。例えば、全てのプロセスインスタンスを重ね合わせて表示する場合には、図５６−２に示すような業務フローが表示されるようになる。この表示では、各イベントクラスを示す楕円は各１個のみ表示し、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため１本のみとしている。図５６−２は、データ生成元の並列処理を含む業務フローと同じであり、システムのデータから、元の業務フローを復元できた例であることを示す。

また、モデルデータ格納部２３に格納されている主要フローフラグのデータを用いて、主要フローと例外フローとを分けて表示する場合には、図７７に示すような表示がなされる。例えば、８０％を分類割合とすると、図７５に示したテーブルにおいて第１及び第２レコードのプロセスインスタンスが重ね合わされて、図７７の第１行目のような業務フローが主要フローとして表示される。主要フロー表示では、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため１本のみとしている。また、図７５に示したテーブルにおいて第３のプロセスインスタンスが、図７７において第２行目の例外フローとして表示される。

以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、例えば図１Ａ及び図１Ｂに示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュールに対応しない。

また、各スコア表も一例であって、確度スコア値の設定の仕方は、経験的にさらに細かく決定される場合もある。さらに、スコア表の項目についても、より少ない項目が設定される場合もあれば、より多くの項目が設定される場合もある。

また、図３の処理フローにおいて、ステップＳ７乃至Ｓ１３については順番の入れ替えが可能であり、また並列に実施するようにしてもよい。

また、判定結果の出力では、各判定項目において「確定」判定や所定の閾値以上の確度スコアとなっているフィールドを自動的に選択してユーザに提示し、自動選択できない判定項目についてユーザに選択又は入力を促すようにしてもよい。

さらに、処理対象フィールドについてのループは、ステップＳ７乃至Ｓ１３内の各々で構成されているが、ステップＳ７乃至Ｓ１３の外側に処理対象フィールドについてのループを出すようにしてもよい。

なお、業務システム分析装置は、コンピュータ装置であって、図７８に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上本実施の形態をまとめると以下のようになる。

本業務フローデータ処理方法は、（Ａ）特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各プロセスインスタンスに含まれるイベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、（Ｂ）統計情報格納部に格納されている各イベント間遷移発生頻度を、該当する発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、発側イベントクラスに属するイベントインスタンスが発生した場合に着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各イベントクラスに属するイベントインスタンスの発生頻度を全種のイベントクラスに属するイベントインスタンスの発生頻度の総和で除することによって、各イベントクラスに属するイベントインスタンスの発生確率を算出し、統計情報格納部に格納するステップと、（Ｃ）特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する条件付き確率と判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの発生確率とを用いて規定される評価式の値を、統計情報格納部に格納されている各イベント間遷移発生頻度に係る各遷移について算出し、統計情報格納部に格納するステップと、（Ｄ）統計情報格納部に格納されている、各遷移の評価式の値のうち所定の閾値未満となっている評価式の値に係る遷移を見かけ上遷移として検出するステップとを含む。

従来の方法に従えばイベントインスタンスを単純に発生日時で時系列に接続してプロセスインスタンスを生成してしまうので、主要経路と当該主要経路から分岐している並列経路とを含むような業務プロセスが実施される場合には問題が生ずる。すなわち、互いに並列関係にある部分フロー中のイベント間に業務フローに対応せず、見かけ上の遷移を誤設定するため、ユーザが業務フローを適切に把握できない。上で述べたような処理を実施することによって、並列経路に属するようなイベントインスタンスと主要経路に属するようなイベントインスタンスとの間の見かけ上遷移を統計的に検出することができるようになり、例えばユーザの確認の下採否を決定することができるようになる。

また、本方法は、プロセスインスタンスデータ格納部に格納されている各プロセスインスタンスについて、特定された見かけ上遷移に該当する遷移を含むか判断し、含む場合には見かけ上遷移に該当する遷移を削除して、見かけ上遷移の削除後のプロセスインスタンスのデータをデータ格納部に格納するステップをさらに含むようにしても良い。このようにすれば、自動的に実際の業務上は発生していないと推定される遷移を排除することができるようになる。

さらに、本方法は、データ格納部に格納されている、見かけ上遷移の削除後の各プロセスインスタンスに含まれる未接続イベントインスタンスの各々について、削除された見かけ上遷移の代わりに発生日時が最も近く且つ見かけ上遷移に該当しないイベントインスタンスを同一プロセスインスタンスにおいて検出して、検出された当該イベントインスタンスとの代替遷移を設定するステップをさらに含むようにしても良い。このように自動的に代替遷移を決定すれば、ユーザの負担を軽減することができる。但し、このように代替遷移を決定した後にさらに自動的に又は手動で修正するようにしても良い。

また、上で述べた評価式が、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの発生確率で除した値と１との差の絶対値を算出する式とする場合もある。このような評価式は、主要経路のイベントインスタンスと並列経路のイベントインスタンスとが独立に発生するという性質に基づくものであって、独立性が弱ければ大きな値となり、独立性が強ければ小さな値になる。

なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出するステップと、
を、コンピュータに実行させるための業務フローデータ処理プログラム。

（付記２）
前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、特定された前記見かけ上遷移に該当する遷移を含むか判断し、含む場合には前記見かけ上遷移に該当する遷移を削除して、前記見かけ上遷移の削除後の前記プロセスインスタンスのデータをデータ格納部に格納するステップ
をさらにコンピュータに実行させるための付記１記載の業務フローデータ処理プログラム。

（付記３）
前記データ格納部に格納されている、前記見かけ上遷移の削除後の各前記プロセスインスタンスに含まれる未接続イベントインスタンスの各々について、削除された前記見かけ上遷移の代わりに発生日時が最も近く且つ前記見かけ上遷移に該当しないイベントインスタンスを同一プロセスインスタンスにおいて検出して、検出された当該イベントインスタンスとの代替遷移を設定するステップ
をさらにコンピュータに実行させるための付記２記載の業務フローデータ処理プログラム。

（付記４）
前記評価式が、
前記判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率を前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率で除した値と１との差の絶対値を算出する式である
付記１乃至３のいずれか１つ記載の業務フローデータ処理プログラム。

（付記５）
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出するステップと、
を含み、コンピュータに実行される業務フローデータ処理方法。

（付記６）
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納する手段と、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納する手段と、
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納する手段と、
前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出する手段と、
を有する業務フローデータ処理装置。

１ 分析対象データ格納部 ３ イベント候補データ生成部
５ イベント候補データ格納部 ７ イベントデータ生成部
９ イベントデータ格納部 １１ 入出力部
１３ プロセスインスタンス生成部 １５ プロセスインスタンスデータ格納部
１７ 並列処理推定部
１９ 並列処理推定後プロセスインスタンスデータ格納部
２１ プロセスインスタンス分類処理部 ２３ モデルデータ格納部
２５ プロセス表示処理部
３１ タイムスタンプ処理部 ３２ イベントＩＤ・関連ＩＤ候補処理部
３４ イベント名処理部 ３５ スコア表格納部
１７１ 統計情報抽出部 １７３ 統計情報格納部
１７５ 見かけ上遷移検出部 １７７ 見かけ上遷移削除部
１７９ 代替遷移決定処理部
１８１ 並列処理該当プロセスインスタンスデータ格納部

Claims (6)

1. 特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
   前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
   特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納するステップと、
   前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出するステップと、
   を、コンピュータに実行させるための業務フローデータ処理プログラム。
2. 前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、特定された前記見かけ上遷移に該当する遷移を含むか判断し、含む場合には前記見かけ上遷移に該当する遷移を削除して、前記見かけ上遷移の削除後の前記プロセスインスタンスのデータをデータ格納部に格納するステップ
   をさらにコンピュータに実行させるための請求項１記載の業務フローデータ処理プログラム。
3. 前記データ格納部に格納されている、前記見かけ上遷移の削除後の各前記プロセスインスタンスに含まれる未接続イベントインスタンスの各々について、削除された前記見かけ上遷移の代わりに発生日時が最も近く且つ前記見かけ上遷移に該当しないイベントインスタンスを同一プロセスインスタンスにおいて検出して、検出された当該イベントインスタンスとの代替遷移を設定するステップ
   をさらにコンピュータに実行させるための請求項２記載の業務フローデータ処理プログラム。
4. 前記評価式が、
   前記判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率を前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率で除した値と１との差の絶対値を算出する式である
   請求項１乃至３のいずれか１つ記載の業務フローデータ処理プログラム。
5. 特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
   前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
   特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納するステップと、
   前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出するステップと、
   を含み、コンピュータに実行される業務フローデータ処理方法。
6. 特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納する手段と、
   前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納する手段と、
   特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納する手段と、
   前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出する手段と、
   を有する業務フローデータ処理装置。

Images