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

Description

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

業務プロセス・リエンジニアリング（ＢＰＲ：Business Process Re-engineering）のために現在企業で運用中の業務システムの分析を行う必要がある。このため、例えば特開２００５−１１５４９４号公報記載のような技術が用いられる。この公報には、以下のような事項が開示されている。

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

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

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

また、上記記載の技術では、業務フローが実施される頻度を分析して、標準的な業務フローと例外的な業務フローとを分類するような構成は開示されておらず、また分類における問題点についても示唆も開示もなされていない。また、業務システムに改変を加えず、かつ、業務実行に不要な負荷を与えることなく、業務システムのデータベースのバックアップデータや業務ログデータ等を用いた分析の方法が存在している。すなわち、複数のテーブル（例えばデータベース）から、イベント名、時刻（イベントの発生日時であるタイムスタンプ）、イベントＩＤ（ここではＩＤ１）及び他の値を含むレコード群と、イベント名、時刻（タイムスタンプ）、ＩＤ１及びＩＤ２などを含むレコード群とが抽出され、第２のイベントクラス（すなわち、イベントの種類）のレコードの関連ＩＤであるＩＤ２のフィールド値が、第１のイベントクラス（すなわち、イベントの種類）のレコードのイベントＩＤであるＩＤ１のフィールド値のいずれかの値をとることにより、第２のイベントクラスの各々のレコード（すなわちイベントインスタンス）が、第１のイベントクラスのどのレコード（すなわちイベントインスタンス）と関連しているかが特定される。
特開２００５−１１５４９４号公報 特開２００８−２７０７２号公報

しかし、業務システムでは、実際に業務を行うことによって生成される業務イベントの他に、業務に無関係なログ生成イベントやプルーフリストの生成イベントなど、システム上発生してしまうようなイベントについても、データベースに登録されてしまう。イベントの名称などで、このようなイベントを削除することができればよいが、必ずしもイベントの名称などで単純に無関係イベントを削除できない場合もある。このような無関係イベントが含まれたままで業務フローを分析すると、分類上、本来同一のグループとすべき業務フローであっても、各々フローの別の箇所に無関係イベントが挿入されたために、別グループの扱いとなる事態が発生する。そのため、本来よりも多数のグループに分類され、かつ、例外フローの数も増大し、業務フロー全体を把握する上で問題となる。

従って、本技術の目的は、業務とは無関係な無関係イベントを自動的に検出し、業務フローから削除することである。

本業務フロー処理方法は、業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、プロセスインスタンスデータ格納部に格納されているプロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どの業務イベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合わせ毎に遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、統計情報格納部に格納されている各イベント間遷移発生頻度を、該当する発側の業務イベントの発生頻度で除することによって、発側の業務イベントが発生した場合に着側の業務イベントが発生する条件付き確率を算出すると共に、各業務イベントの発生頻度を業務イベント全部の発生頻度の和で除することによって、各業務イベントの発生確率を算出し、統計情報格納部に格納するステップと、業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係を基に、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率及び判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ判断対象の業務イベントのイベントクラスが無関係イベントのイベントクラスであるか否か判断するための評価式の値を、統計情報格納部に格納されている業務イベントのイベントクラスに属するイベントインスタンスの発生確率と条件付き確率とを用いて算出するステップと、評価値が所定の閾値以下である判断対象の業務イベントのイベントクラスを特定し、プロセスインスタンスデータ格納部に格納されているプロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納するステップとを含む。

業務とは無関係な無関係イベントを自動的に検出し、業務フローから削除することができる。

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

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

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

また、図１Ｂに示すように、無関係イベント削除部１７は、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスにおけるイベント発生状況から各種統計データを算出する統計情報抽出部１７１と、統計情報抽出部１７１によって算出された統計情報を格納する統計情報格納部１７３と、統計情報格納部１７３に格納されているデータを用いてプロセスインスタンスに含まれるイベントのうち無関係イベントを検出する無関係イベント検出部１７５と、無関係イベント検出部１７５によって検出された無関係イベントのイベントクラスに属するイベントインスタンスをプロセスインスタンスから削除する処理を実施する無関係イベント削除部１７７とを有する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このようなグループＡ乃至Ｄのプロセスインスタンスのグループを重ね合わせ表示すると、図４９に示すような全体フローが生成される。この表示では、各イベントクラスを示す楕円は各1個のみ表示し、同一のイベントクラス間の遷移を表す矢印は煩雑を避けるため1本のみとしている。また、繰り返し、手戻りを見やすくするため、点線で表示している。

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

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

一方、図５１に示すように、図４８のプロセスインスタンスに、業務とは無関係のシステム管理用のイベントである記録というイベントクラスに属するイベントインスタンスが挿入されたようなプロセスインスタンスが生成された場合には、図４８のような場合とは異なり、問題が生ずる。ここで、図５１では、見やすくするため、記録というイベントクラスに属するイベントインスタンス及びそこに到着する遷移及びそこから出発する遷移を点線で示す。図５１の例では、Initial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateというフローを基本として、記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスＡ’が２つ生成されている。加えて、上記基本のフローにおいて契約満了とFinal Stateとの間に記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスＡ”が１つ生成されている。さらに、上記基本のフローにおいて契約と伝票作成との間に記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスＡ'''が１つ生成されている。また、上記基本のフローにおいてInitial Stateと契約との間に記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスＡ""が１つ生成されている。また、Initial State、契約、伝票作成、請求、回収、契約更新、伝票作成、請求、回収、契約満了及びFinal Stateというフローを第２の基本フローとして、１回目の請求と回収との間に記録というイベントクラスに属するイベントインスタンスと、回収と契約満了との間に記録というイベントクラスに属するイベントインスタンスとが挿入されているプロセスインスタンスＢ’が１つ生成されている。また、上記第２の基本フローにおいて２回目の伝票作成と請求との間に記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスＢ”が１つ生成されている。さらに、上記第２の基本フローにおいて回収と契約満了との間に記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスＢ'''が１つ生成されている。また、Initial State、契約、伝票作成、請求、回収、継続、請求、回収、契約満了及びFinal StateというフローのプロセスインスタンスＣが１つ生成されている。さらに、Initial State、契約、伝票作成、請求、回収、回収、契約満了及びFinal Stateという第３の基本フローとして、請求と回収との間に記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスＤ’が１つ生成されている。

このように、業務フローとは無関係の記録というイベントクラスに属するイベントインスタンスが挿入されているプロセスインスタンスをそれぞれ異なるものとして単純に分類を行うと、同じグループであると判断されるプロセスインスタンスは、非常に少なくなる。図５１の例では、プロセスインスタンスＡ’のみが２つあるのでグループとしても、その出現頻度が全体に占める比率は２０％で、図５２に示すようにその他を例外フローとすると、例外フローの出現頻度が全体に占める比率が８０％となり、主要フローのみで業務フローの概要を把握することは妥当でない。ここで、図５２では、見やすくするため、記録というイベントクラスに属するイベントインスタンス及びそこに到着する遷移及びそこから出発する遷移を点線で示す。例外フロー１乃至３は、記録というイベントクラスに属するイベントインスタンスさえなければ主要フローに統合できる。また、例外フロー４乃至６についても、記録というイベントクラスに属するイベントインスタンスさえなければ主要フローに統合できる。当然、図５３に示すように、全プロセスインスタンスを重ね合わせても、記録というイベントクラスに属するイベントインスタンスによって全体フローも複雑になってしまう。この表示では、各イベントクラスを示す楕円は各1個のみ表示し、同一のイベントクラス間の遷移を表す矢印は煩雑を避けるため1本のみとしている。また、記録というイベントクラスに属するイベントインスタンス及びそこに到着する遷移及びそこから出発する遷移を点線で示す。

そこで、図５４乃至図６６に示すような処理を実施することによって、業務の全体像の把握を困難にしている、業務フローに無関係なイベントクラスに属するイベントインスタンスを、プロセスインスタンスから削除することによって、本来同一グループに分類されるべきプロセスインスタンスが別グループに分類されることを防止することで、ユーザが本来の業務フローの概要を把握できるようにする。なお、無関係イベントは、システム管理用イベントに限定されるわけではなく、例えば、無関係な２以上の業務フローを１つのデータベースで管理するような場合には、互いに他方の業務フローのイベントクラスについても無関係イベントと取り扱う。

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

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

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

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

次に、統計情報抽出部１７１は、統計情報格納部１７３に格納されている各イベントの発生確率及び条件付き確率に基づき、無関係イベント検出指標値を各イベントについて算出し、統計情報格納部１７３に格納する（ステップＳ１１５）。

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

ここで、当該分析対象の業務プロセスの業務イベントとは関係無く発生する無関係イベントについて、無関係イベントの発生という事象は、他の業務イベントの発生と独立とみなせる。したがって、他のイベントが発生した場合に無関係イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率Ｐ（無関係イベント｜他のイベント）と、無関係イベントのイベントクラスに属するイベントインスタンスの発生確率Ｐ（無関係イベント）について、Ｐ（無関係イベント｜他のイベント）＝Ｐ（無関係イベント）が成立する。

すなわち、｜１−Ｐ（無関係イベント｜他のイベント）／Ｐ（無関係イベント）｜＝０が導出される。従って、本実施の形態における第１の実施例の無関係イベント検出指標としては、｜１−Ｐ（判断対象イベント｜他のイベント）／Ｐ（判断対象イベント）｜を採用する。

その上で、｜１−Ｐ（判断対象イベント｜他のイベント）／Ｐ（判断対象イベント）｜を、当該判断対象の業務イベントを固定し他の業務イベントとの組み合わせ全てについて計算したものの総和を無関係イベント検出指標値として計算すると共に、閾値として「当該判断対象の業務イベントと他の業務イベントとの組み合わせの総数」を採用する。

図６０及び図６１から第１の実施例の無関係イベント指標及びその合計値（実際の無関係イベント検出指標値）を算出すると、図６３に示すような値が得られる。ここで、上記記載の無関係イベント検出指標は、イベント間遷移頻度表に対応付けると、｜１−Ｐ（着側イベント｜発側イベント）／Ｐ（着側イベント）｜となる。図６３に示した例では、最下行以外は第１の実施例の無関係イベント検出指標の値を表しており、最下行は、無関係イベント検出指標値を表している。記録というイベントクラスについての第１の実施例の無関係イベント検出指標値は、閾値である「８」（＝当該判断対象の業務イベントと他の業務イベントとの組み合わせの総数）を唯一下回るイベントクラスとなっているので、無関係イベントとして検出することができる。

上で述べた第１の実施例の無関係イベント検出指標を採用せず、他の指標を用いるようにしても良い。例えば、イベント間遷移頻度表と、イベントの発生確率及び条件付き確率とを用いて、以下のような第２の実施例の無関係イベント検出指標を用いる場合もある。
｜Ｐ（判断対象イベント）−Ｐ（判断対象イベント｜他のイベント）｜・（Ｆ（判断対象イベント｜他のイベント））^1/2
第２の実施例の無関係イベント検出指標も、｜Ｐ（無関係イベント）−Ｐ（無関係イベント｜他のイベント）｜＝０」が成り立つことを利用している。その上で、統計学的にサンプル数が多いほど、すなわち、イベント間遷移頻度が高くなるほど、イベント発生確率及び条件付き確率の近似値の値が正確に出るはず、即ち、判断対象イベントが無関係イベントであれば、｜Ｐ（判断対象イベント）−Ｐ（判断対象イベント｜他のイベント）｜の値はより「０」に近くなるはずであるので、そうならないペナルティ加重として、イベント間遷移発生頻度の平方根（Ｆ（判断対象イベント｜他のイベント））^1/2を乗じている。上記記載の無関係イベント検出指標は、イベント間遷移頻度表に対応付けると、｜Ｐ（着側イベント）−Ｐ（着側イベント｜発側イベント）｜・（Ｆ（着側イベント｜発側イベント））^1/2となる。

なお、閾値と比較する無関係イベント検出指標値は、以下のとおりである。
第１の値＝Σ_{着側イベントと同一でない発側イベントとの全組み合わせ}{｜Ｐ（着側イベント）−Ｐ（着側イベント｜発側イベント）｜・（Ｆ（着側イベント｜発側イベント））^1/2 }
第２の値＝Σ_{着側イベントと同一でない発側イベントとの全組み合わせ}{｜Ｐ（着側イベント）−Ｐ（着側イベント｜発側イベント）｜・（Ｆ（着側イベント｜発側イベント））^1/2 }／（Ｔ（着側イベント））²
また、第２の値を算出する際に、着側イベントの発生頻度の２乗（Ｔ（着側イベント））²で除しているのは、イベント発生頻度が低いことの影響を下げるためである。

なお、判断対象イベントクラスの第１及び第２の値について、各々他のイベントクラスの値と比較したときに明らかに小さいという条件が、第１及び第２の値の両方について成り立つ場合に、そのイベントクラスを無関係イベントとして検出する。明らかに小さいという条件は、例えば第１及び第２の値の各々について、全イベントクラスの平均値及び標準偏差の値を用いて算出した（平均−標準偏差）と比較して小さいという条件を用いる。

このような第２の実施例の無関係イベント検出指標値を採用した場合の例を図６４に示す。図６４の例では、下から２番目の行は、第１の値の計算結果を表しており、最下行は、第２の値の計算結果を表している。第１の値の平均値は１．７６であり、標準偏差は１．２５であり、（平均値−標準偏差）＝０．５１である。これだけを判断基準にすると、無関係イベントである記録というイベントクラスの値と継続イベントクラスの値と契約更新というイベントクラスの値が、０．５１以下となってしまう。一方、第２の値の平均値は０．０２であり、標準偏差は０．０１であり、（平均値−標準偏差）＝０．０１である。第２の値について（平均値−標準偏差）＝０．０１と比較すると、当該値以下となるのは記録というイベントクラスと回収というイベントクラスと契約満了というイベントクラスである。したがって、第１及び第２の値の両方について、条件を満たすイベントクラスである記録というイベントクラスを無関係イベントとして検出することができる。

無関係イベント検出部１７５は、統計情報格納部１７３に格納されている指標値（すなわち、閾値と比較する無関係イベント検出指標値）が閾値以下であるイベントクラスを無関係イベントとして検出し、無関係イベント削除部１７７に出力する（ステップＳ１１９）。端子Ａを介して図６５の処理に移行する。

無関係イベント削除部１７７は、無関係イベント検出部１７５から無関係イベントのイベントクラスに属するイベントインスタンスのデータ（例えばＩＤ）を受け取り、受け取った無関係イベントのイベントクラスに属するイベントインスタンスのうち未処理の無関係イベントのイベントクラスに属するイベントインスタンスを１つ特定する（ステップＳ１２１）。そして、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスのうち、特定された無関係イベントのイベントクラスに属するイベントインスタンスを含むプロセスインスタンスを特定する（ステップＳ１２３）。

そして、無関係イベント削除部１７７は、特定されたプロセスインスタンスの各々について、無関係イベントのイベントクラスに属するイベントインスタンスを削除し、前後のイベントを直接接続し、修正後のプロセスインスタンスのデータを無関係イベント削除済みプロセスインスタンスデータ格納部１９に格納する（ステップＳ１２５）。そして、全ての無関係イベントのイベントクラスに属するイベントインスタンスについて処理したか判断する（ステップＳ１２７）。未処理の無関係イベントが存在する場合にはステップＳ１２１に戻る。一方、全ての無関係イベントのイベントクラスに属するイベントインスタンスを処理した場合には元の処理に戻る。

ステップＳ１２５を実施すると、例えば図６６に示すようなプロセスインスタンスが得られる。このように、Ａグループは、Initial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateというフローの５つのプロセスインスタンスを含む。また、Ｂグループは、Initial State、契約、伝票作成、請求、回収、契約更新、伝票作成、請求、回収、契約満了及びFinal Stateというフローの３つのプロセスインスタンスを含む。さらに、Ｃグループは、Initial State、契約、伝票作成、請求、回収、継続、請求、回収、契約満了及びFinal Stateというフローの１つのプロセスインスタンスを含む。また、Ｄグループは、Initial State、契約、伝票作成、請求、回収、回収、契約満了及びFinal Stateというフローの１つのプロセスインスタンスを含む。

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

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

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

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

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

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

図３の説明に戻って、フロー表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、入出力部１１を介して処理結果を出力する（ステップＳ２７）。例えば、全てのプロセスインスタンスを重ね合わせて表示する場合には、図６９に示すような業務フローが表示されるようになる。この表示では、各イベントクラスを示す楕円は各1個のみ表示し、同一のイベントクラス間の遷移を表す矢印は煩雑を避けるため1本のみとしている。図６９で示すように、継続を経由する手戻りと契約更新を経由する手戻りと、回収の繰り返しがそれぞれ１つだけ存在するような表示になる。

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

このような処理を実施すれば、図５２のような分類及び表示と比べて、整理された形で業務フローが提示されるため、ユーザは、実際に実施されている業務フローの概要をより把握しやすくなる。すなわち、特徴を把握する上で業務の全体像の把握を困難にしている無関係イベントが削除されているので、繰り返しの有無や仕方、手戻りの有無や仕方を、把握しやすくなる。

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

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

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

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

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

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

本業務フロー処理方法は、業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、プロセスインスタンスデータ格納部に格納されているプロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どのイベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合わせ毎に遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、統計情報格納部に格納されている各イベント間遷移発生頻度を、該当する発側の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度で除することによって、発側の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に着側の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各業務イベントのイベントクラスに属するイベントインスタンスの発生頻度を業務イベントのイベントクラスに属するイベントインスタンス全部の発生頻度の和で除することによって、各業務イベントのイベントクラスに属するイベントインスタンスの発生確率を算出し、統計情報格納部に格納するステップと、業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係（例えば、他の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に無関係イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率は当該無関係イベントのイベントクラスに属するイベントインスタンスの発生確率に等しくなるという関係）を基に、当該判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率及び判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ判断対象の業務イベントのイベントクラスが無関係イベントのイベントクラスであるか否か判断するための評価式の値を、統計情報格納部に格納されている業務イベントのイベントクラスに属するイベントインスタンスの発生確率と条件付き確率とを用いて算出するステップと、評価値が所定の閾値以下である判断対象の業務イベントのイベントクラスを特定し、プロセスインスタンスデータ格納部に格納されているプロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納するステップとを含む。

上記のような評価式を採用することによって、判断対象の業務イベントが無関係イベントであるか否かを無関係イベントの統計的性質を用いて自動的に判断することができるようになり、ユーザが業務フローを分析する上で必要な業務イベントのイベントクラスに属するイベントインスタンスを含むプロセスインスタンスを生成することができるようになる。すなわち、適切な業務フローの分析を行うことができるようになる。

なお、上で述べた評価式は、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率で除した値と１との差の絶対値を、当該判断対象の業務イベントのイベントクラスと、他の業務イベントのイベントクラスとの全ての組み合わせについて計算したものの総和（すなわち、Σ_{他の業務イベントとの組み合わせ全て}{｜１−Ｐ（判断対象イベント｜他のイベント）／Ｐ（判断対象イベント）｜}）である場合もある。このような評価式を採用することによって、無関係イベントであるか否かを判断するための評価値を簡単に算出することができるようになる。なお、この際には所定の閾値が、（当該判断対象の業務イベントと他の業務イベントとの組み合わせの総数）とすればよい。

さらに、上で述べた評価式が、２つの評価式で構成される場合もある。判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率と、当該判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率との差の絶対値と、当該判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスから当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスへのイベント間遷移発生頻度の平方根との積を、当該判断対象の業務イベントのイベントクラスと、他の業務イベントのイベントクラスとの全ての組み合わせについて計算したものの総和である第１の評価式（第１の評価式：Σ_{他の業務イベントとの組み合わせ全て}{｜Ｐ（判断対象イベント）−Ｐ（判断対象イベント｜他のイベント）｜・（Ｆ（判断対象イベント｜他のイベント））^1/2}）と、第１の評価式の値を判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度の二乗で除する第２の評価式（第２の評価式：Σ_{他の業務イベントとの組み合わせ全て}{｜Ｐ（判断対象イベント）−Ｐ（判断対象イベント｜他のイベント）｜・（Ｆ（判断対象イベント｜他のイベント））^1/2 }／（Ｔ（判断対象イベント））²）である場合もある。この際、第１の評価式の所定の閾値が、判断対象の業務イベントの候補となるイベントクラスの全てについて算出した第１の評価式の値の平均値から、判断対象の業務イベントの候補となるイベントクラスの全てについて算出した第１の評価式の値の標準偏差を減じた値である場合もある。また、第２の評価式の所定の閾値が、判断対象の業務イベントの候補となるイベントクラスの全てについて算出した第２の評価式の値の平均値から、判断対象の業務イベントの候補となるイベントクラスの全てについて算出した第２の評価式の値の標準偏差を減じた値である場合もある。このような２つの評価式の値が両方とも対応する閾値以下である場合には、判断対象の業務イベントは無関係イベントと判断される。

評価式は、このように様々な式に変形可能であるが、基本的には、無関係イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に無関係イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率は当該無関係イベントのイベントクラスに属するイベントインスタンスの発生確率に等しくなるという関係を基に規定される。

さらに、本業務フロー処理方法は、修正後プロセスインスタンスデータ格納部に格納されているプロセスインスタンスを、構成要素であるイベントインスタンスの属するイベントクラスに基づき分類して作成したグループ毎に計数するステップと、計数結果に基づき、出現頻度が所定基準以上となっており且つ修正後プロセスインスタンスデータ格納部に格納されているプロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップとをさらに含むようにしても良い。ユーザは、業務をより分析しやすくなる。

また、上で述べた出力ステップが、特定されたプロセスインスタンスを重ね合わせるステップを含むようにしてもよい。このようにすれば無駄に多くのプロセスインスタンスを提示しなくなるので、ユーザは業務フローを把握しやすくなる。

さらに、上で述べた出力ステップが、特定されたプロセスインスタンス以外のプロセスインスタンスを、例外フローとして出力するステップを含むようにしてもよい。どのような例外フローが存在するかを把握しやすくなる。

なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

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

（付記１）
業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、前記案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どの業務イベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合わせ毎に遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に前記着側の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生頻度を記業務イベントのイベントクラス全部に属するイベントインスタンスの発生頻度の和で除することによって、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
前記業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ前記業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係を基に、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率及び前記判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ前記判断対象の業務イベントのイベントクラスが前記無関係イベントのイベントクラスであるか否か判断するための評価式の値を、前記統計情報格納部に格納されている前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率と前記条件付き確率とを用いて算出するステップと、
前記評価値が所定の閾値以下である前記判断対象の業務イベントのイベントクラスを特定し、前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納するステップと、
を、コンピュータに実行させるための業務フロー処理プログラム。

（付記２）
前記評価式が、
前記判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率で除した値と１との差の絶対値を、当該判断対象の業務イベントのイベントクラスと、他の業務イベントのイベントクラスとの全ての組み合わせについて計算したものの総和
であり、
前記所定の閾値が、（当該判断対象の業務イベントと他の業務イベントとの組み合わせの総数）である
付記１記載の業務フロー処理プログラム。

（付記３）
前記評価式が、
前記判断対象の業務イベントのイベントクラスに属するイベントインスタンス発生確率と、当該判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率との差の絶対値と、当該判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスから当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスへのイベント間遷移発生頻度の平方根との積を、当該判断対象の業務イベントのイベントクラスと、他の業務イベントのイベントクラスとの全ての組合せについて計算したものの総和である第１の評価式と、
前記第１の評価式の値を前記判断対象の業務イベントの発生頻度の二乗で除する第２の評価式と、
を含み、
前記第１の評価式の所定の閾値が、前記判断対象の業務イベントの候補となるイベントクラスの全てについて算出した前記第１の評価式の値の平均値から、前記判断対象の業務イベントの候補となるイベントクラスの全てについて算出した前記第１の評価式の値の標準偏差を減じた値であり、
前記第２の評価式の所定の閾値が、前記判断対象の業務イベントの候補となるイベントクラスの全てについて算出した前記第２の評価式の値の平均値から、前記判断対象の業務イベントの候補の全てについて算出した前記第２の評価式の値の標準偏差を減じた値である
付記１記載の業務フロー処理プログラム。

（付記４）
前記修正後プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、構成要素であるイベントインスタンスの属するイベントクラスに基づき分類して作成したグループ毎に計数するステップと、
前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記修正後プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップと、
をさらに前記コンピュータに実行させるための付記１記載の業務フロー処理プログラム。

（付記５）
前記出力ステップが、
特定された前記プロセスインスタンスを重ね合わせるステップ
を含む付記４記載の業務フロー処理プログラム。

（付記６）
前記出力ステップが、
特定された前記プロセスインスタンス以外のプロセスインスタンスを、例外フローとして出力するステップ
を含む付記４記載の業務フロー処理プログラム。

（付記７）
業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、前記案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どの業務イベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合わせ毎に遷移の発生頻度をイベント感染に発生頻度として計数し、統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に前記着側の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生頻度を前記業務イベントのイベントクラス全部に属するイベントインスタンスの発生頻度の和で除することによって、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
前記業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ前記業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係を基に、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率及び前記判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ前記判断対象の業務イベントのイベントクラスが前記無関係イベントのイベントクラスであるか否か判断するための評価式の値を、前記統計情報格納部に格納されている前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率と前記条件付き確率とを用いて算出するステップと、
前記評価値が所定の閾値以下である前記判断対象の業務イベントのイベントクラスを特定し、前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納するステップと、
を含み、コンピュータに実行される業務フロー方法。

（付記８）
業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、前記案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納する手段と、
前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どの業務イベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合わせ毎に遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納する手段と、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に前記着側の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記務イベントのイベントクラスに属するイベントインスタンスの発生頻度を前記業務イベントのイベントクラス全部に属するイベントインスタンスの発生頻度の和で除することによって、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納する手段と、
前記業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ前記業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係を基に、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率及び前記判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ前記判断対象の業務イベントのイベントクラスが前記無関係イベントのイベントクラスであるか否か判断するための評価式の値を、前記統計情報格納部に格納されている前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率と前記条件付き確率とを用いて算出する手段と、
前記評価値が所定の閾値以下である前記判断対象の業務イベントのイベントクラスを特定し、前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納する手段と、
を有する業務フロー処理装置。

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

符号の説明

１ 分析対象データ格納部 ３ イベント候補データ生成部
５ イベント候補データ格納部 ７ イベントデータ生成部
９ イベントデータ格納部 １１ 入出力部
１３ プロセスインスタンス生成部 １５ プロセスインスタンスデータ格納部
１７ 無関係イベント削除部
１９ 関係イベント削除済みプロセスインスタンスデータ格納部
２１ プロセスインスタンス分類処理部 ２３ モデルデータ格納部
２５ プロセス表示処理部
３１ タイムスタンプ処理部 ３２ イベントＩＤ・関連ＩＤ候補処理部
３４ イベント名処理部 ３５ スコア表格納部
１７１ 統計情報抽出部 １７３ 統計情報格納部
１７５ 無関係イベント検出部 １７７ 無関係イベント削除部

Claims (7)

1. 業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、前記案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
   前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どの業務イベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合わせ毎に遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
   前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に前記着側の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生頻度を前記業務イベント全部のクラスに属するイベントインスタンスの発生頻度の和で除することによって、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
   前記業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ前記業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係を基に、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率及び前記判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ前記判断対象の業務イベントのイベントクラスが前記無関係イベントのイベントクラスであるか否か判断するための評価式の値を、前記統計情報格納部に格納されている前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率と前記条件付き確率とを用いて算出するステップと、
   前記評価値が所定の閾値以下である前記判断対象の業務イベントのイベントクラスを特定し、前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納するステップと、
   を、コンピュータに実行させるための業務フロー処理プログラム。
2. 前記評価式が、
   前記判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率で除した値と１との差の絶対値を、当該判断対象の業務イベントのイベントクラスと、他の業務イベントのイベントクラスとの全ての組み合わせについて計算したものの総和
   であり、
   前記所定の閾値が、当該判断対象の業務イベントと他の業務イベントとの組み合わせの総数である
   請求項１記載の業務フロー処理プログラム。
3. 前記評価式が、
   前記判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率と、当該判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率との差の絶対値と、当該判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスから当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスへのイベント間遷移発生頻度の平方根との積を、当該判断対象の業務イベントのイベントクラスと、他の業務イベントのイベントクラスとの全ての組み合わせについて計算したものの総和である第１の評価式と、
   第１の評価式の値を前記判断対象の業務イベントの発生頻度の二乗で除する第２の評価式と、
   を含み、
   前記第１の評価式の所定の閾値が、前記判断対象の業務イベントの候補となるイベントクラスの全てについて算出した前記第１の評価式の値の平均値から、前記判断対象の業務イベントの候補となるイベントクラスの全てについて算出した前記第１の評価式の値の標準偏差を減じた値であり、
   前記第２の評価式の所定の閾値が、前記判断対象の業務イベントの候補となるイベントクラスの全てについて算出した前記第２の評価式の値の平均値から、前記判断対象の業務イベントの候補となるイベントクラスの全てについて算出した前記第２の評価式の値の標準偏差を減じた値である
   請求項１記載の業務フロー処理プログラム。
4. 前記修正後プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、構成要素であるイベントインスタンスの属するイベントクラスに基づき分類して作成したグループ毎に計数するステップと、
   前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記修正後プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップと、
   をさらに前記コンピュータに実行させるための請求項１記載の業務フロー処理プログラム。
5. 前記出力ステップが、
   特定された前記プロセスインスタンスを主要な業務フローに重ね合わせて出力するステップ
   を含む請求項４記載の業務フロー処理プログラム。
6. 業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、前記案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
   前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どの業務イベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合わせ毎に遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
   前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に前記着側の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生頻度を前記業務イベント全部のクラスに属するイベントインスタンスの発生頻度の和で除することによって、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
   前記業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ前記業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係を基に、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントが発生する条件付き確率及び前記判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ前記判断対象の業務イベントのイベントクラスが前記無関係イベントのイベントクラスであるか否か判断するための評価式の値を、前記統計情報格納部に格納されている前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率と前記条件付き確率とを用いて算出するステップと、
   前記評価値が所定の閾値以下である前記判断対象の業務イベントのイベントクラスを特定し、前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納するステップと、
   を含み、コンピュータに実行される業務フロー処理方法。
7. 業務処理の結果を格納するデータベースから案件毎に実施された一連の業務イベントのデータを抽出して、前記案件毎に実施された業務イベントのイベントクラスに属するイベントインスタンスを時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納する手段と、
   前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスのデータから、プロセスインスタンス中のイベントインスタンスの遷移における発側及び着側のイベントインスタンスが各々どのイベントクラスに属しているかに応じて、発側の業務イベントのイベントクラスと着側の業務イベントのイベントクラスとの組み合せ毎に遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納する手段と、
   前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側の業務イベントのイベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に前記着側の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生頻度を前記業務イベント全部のクラスに属するイベントインスタンスの発生頻度の和で除することによって、各前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納する手段と、
   前記業務処理とは無関係であるにもかかわらず業務イベントとして抽出され且つ前記業務処理に係る他の業務イベントと独立に発生する無関係イベントに関してのみ成り立つ関係を基に、判断対象の業務イベント以外の業務イベントのイベントクラスに属するイベントインスタンスが発生した場合に当該判断対象の業務イベントのイベントクラスに属するイベントインスタンスが発生する条件付き確率及び前記判断対象の業務イベントのイベントクラスに属するイベントインスタンスの発生確率を用いて定義され且つ前記判断対象の業務イベントのイベントクラスが前記無関係イベントのイベントクラスであるか否か判断するための評価式の値を、前記統計情報格納部に格納されている前記業務イベントのイベントクラスに属するイベントインスタンスの発生確率と前記条件付き確率とを用いて算出する手段と、
   前記評価値が所定の閾値以下である前記判断対象の業務イベントのイベントクラスを特定し、前記プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスから当該イベントクラスに属するイベントインスタンスを削除して修正後プロセスインスタンスを生成し、修正後プロセスインスタンスデータ格納部に格納する手段と、
   を有する業務フロー処理装置。

Images