(57)【要約】  業務フローの分類を適切に実施できるようにしてユーザに実施されている業務フロー全体の特徴を把握しやすくするために、本業務フロー処理方法は、業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成するステップと、各プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から先に実施された第２の業務に戻る手戻りが発生しているか判断するステップと、手戻りが発生しているプロセスインスタンスについて、手戻りのパターン種別毎に当該手戻りの重複手戻りを削除するステップと、重複手戻り削除後のプロセスインスタンスを、種別毎に計数するステップと、計数結果に基づき、出現頻度が所定基準以上となっており且つ重複手戻り削除後のプロセスインスタンスを特定し、主要な業務フローとして出力するステップとを含む。
2009104276.tif 000002
【特許請求の範囲】
【請求項１】
業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、前記案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から、先に実施された第２の業務に戻る手戻りが発生しているか判断するステップと、
前記手戻りが発生している前記プロセスインスタンスについて、前記手戻りのパターン種別毎に当該手戻りの重複手戻りを削除し、前記重複手戻り削除後の前記プロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納するステップと、
前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、種別毎に計数するステップと、
前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップと、
を、コンピュータに実行させるための業務フロー処理プログラム。
【請求項２】
前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第３の業務から当該第３の業務に戻る繰り返しが発生しているか判断するステップと、
前記繰り返しが発生している前記プロセスインスタンスについて、前記繰り返しのパターン種別毎に当該繰り返しの重複繰り返しを削除し、前記重複繰り返し削除後のプロセスインスタンスを、前記プロセスインスタンスデータ格納部に格納するステップと、
をさらに前記コンピュータに実行させるための請求項１記載の業務フロー処理プログラム。
【請求項３】
前記簡略化プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第３の業務から当該第３の業務に戻る繰り返しが発生しているか判断するステップと、
前記繰り返しが発生している前記プロセスインスタンスについて、前記繰り返しのパターン種別毎に当該繰り返しの重複繰り返しを削除し、前記重複繰り返し削除後のプロセスインスタンスを、前記簡略化プロセスインスタンスデータ格納部に格納するステップと、
をさらに前記コンピュータに実行させるための請求項１記載の業務フロー処理プログラム。
【請求項４】
前記出力ステップが、
特定された前記プロセスインスタンスを重ね合わせるステップ
を含む請求項１記載の業務フロー処理プログラム。
【請求項５】
前記出力ステップが、
特定された前記プロセスインスタンス以外のプロセスインスタンスを、例外フローとして出力するステップ
を含む請求項１記載の業務フロー処理プログラム。
【請求項６】
業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、前記案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から、先に実施された第２の業務に戻る手戻りが発生しているか判断するステップと、
前記手戻りが発生している前記プロセスインスタンスについて、前記手戻りのパターン種別毎に当該手戻りの重複手戻りを削除し、前記重複手戻り削除後の前記プロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納するステップと、
前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、種別毎に計数するステップと、
前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップと、
を含み、コンピュータに実行される業務フロー処理方法。
【請求項７】
業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、前記案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納する手段と、
前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から、先に実施された第２の業務に戻る手戻りが発生しているか判断する手段と、
前記手戻りが発生している前記プロセスインスタンスについて、前記手戻りのパターン種別毎に当該手戻りの重複手戻りを削除し、前記重複手戻り削除後の前記プロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納する手段と、
前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、種別毎に計数する手段と、
前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力手段と、
を有する業務フロー処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務プロセス分析のための情報処理技術に関する。
【背景技術】
【０００２】
業務プロセス・リエンジニアリング（ＢＰＲ：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という流れと基本として、回収というイベントインスタンスが１回繰り返されるプロセスインスタンスが２つと、回収というイベントインスタンスが２回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが３回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが４回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが５回繰り返されるプロセスインスタンスが１つ生成されている。残りのプロセスインスタンスについても、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という遷移が行われるプロセスインスタンスが１つ含まれるグループとに分類される。従って、モデルデータ格納部２３には、図６３に示すようなデータが格納される。図６３の例では、上で述べた３つのグループのプロセスインスタンスと、それぞれの計数値が登録されている。なお、主要フローフラグの欄には、この段階では何も登録されない。【０１２３】
そして、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、フロー表示処理を実施する（ステップＳ２５）。フロー表示処理について図６４乃至図６６を用いて説明する。【０１２４】
まず、フロー表示処理部２５は、モデルデータ格納部２３に格納されているプロセスインスタンスのグループを計数値に基づき降順に整列させる（ステップＳ１４１）。そして、各プロセスのグループを主要フローとして扱うための判断基準となる、当該グループのプロセスインスタンスの総数に占める比率の閾値を、ユーザから入力された場合には当該入力値により、ユーザの入力がない場合には予め設定されている値で決定する（ステップＳ１４３）。例えば総数に占める比率の閾値２０％以上のグループを主要フローと分類する場合には、２０％を入力する。但し、予め設定されている値（例えば３０％）をそのまま用いるようにしても良い。【０１２５】
そして、フロー表示処理部２５は、計数値上位より１つ未選択のプロセスインスタンスを選択する（ステップＳ１４７）。この選択されたプロセスインスタンスを主要フロー（典型フローとも呼ぶ）に指定する（ステップＳ１４９）。具体的には、モデルデータ格納部２３のテーブルにおける主要フローフラグをオンにセットする。そして、各グループの全体に対して占める比率≧閾値であるか判断する（ステップＳ１５３）。この条件が満たされている場合にはステップＳ１４７に戻る。【０１２６】
例えば、図６３の例では、最初に第１レコードを選択すると、全体に占める比率が６０％となり、閾値が２０％であれば、ステップＳ１４７に戻る。次に、第２レコードを選択すると、全体に占める比率は３０％となり、同様に、ステップＳ１４７に戻る。このように第１レコード及び第２レコードについて主要フローフラグがオンにセットされる。【０１２７】
最後に、第３レコードを選択すると、全体に占める比率が１０％となり、全体に占める比率≧閾値という条件が満たされなくなるので、フロー表示処理部２５は、元の処理に戻る。このようにすれば、ステップＳ１４７で選択されたプロセスインスタンスのグループ以外のプロセスインスタンスは、主要フローフラグがオンにセットされていないので、例外フローとして特定されたことになる。【０１２８】
図３の説明に戻って、フロー表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、入出力部１１を介して処理結果を出力する（ステップＳ２７）。例えば、全てのプロセスインスタンスを重ね合わせて表示する場合には、図６５に示すような業務フローが表示されるようになる。図６５で示すように、継続を経由する手戻りと契約更新を経由する手戻りと、回収の繰り返しがそれぞれ１つだけ存在するような表示になる。【０１２９】
また、モデルデータ格納部２３に格納されている主要フローフラグのデータを用いて、主要フローと例外フローとを分けて表示する場合には、図６６に示すような表示がなされる。例えば、９０％を分類割合としていると、図６３に示したテーブルにおいて第１及び第２レコードのプロセスインスタンスが重ね合わされて、図６６の上段のような業務フローが主要フローとして表示される。また、図６３に示したテーブルにおいて第３のプロセスインスタンスが、例外フローとして表示される。【０１３０】
このような処理を実施すれば、図５２のような分類及び表示と比べて、非常に整理された形で業務フローが提示されるため、ユーザは、実際に実施されている業務フローの概要をより把握しやすくなる。すなわち、特徴を把握する上で業務の全体像の把握を困難にしている手戻りや繰り返しが省略されているので、繰り返しの有無や仕方、手戻りの有無や仕方を、把握しやすくなる。【０１３１】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、例えば図１に示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュールに対応しない。【０１３２】
また、業務の全体像の把握を困難にしている手戻りを削除してプロセスインスタンスを再構築する際には、図５９に示すように手戻りが１箇所に複数存在する場合には、その順番を一定のルールで定めておかないと異なるプロセスインスタンスとして認識されてしまう。例えば、手戻りの長さが短い順に並べてからプロセスインスタンスを再構築するというルールを採用すれば、手戻りの順番が異なる実質的に同じプロセスインスタンスが生成されることが無くなる。【０１３３】
また、各スコア表も一例であって、確度スコア値の設定の仕方は、経験的にさらに細かく決定される場合もある。さらに、スコア表の項目についても、より少ない項目が設定される場合もあれば、より多くの項目が設定される場合もある。【０１３４】
また、図３の処理フローにおいて、ステップＳ７乃至Ｓ１３については順番の入れ替えが可能であり、また並列に実施するようにしてもよい。【０１３５】
また、判定結果の出力では、各判定項目において「確定」判定や所定の閾値以上の確度スコアとなっているフィールドを自動的に選択してユーザに提示し、自動選択できない判定項目についてユーザに選択又は入力を促すようにしてもよい。【０１３６】
さらに、処理対象フィールドについてのループは、ステップＳ７乃至Ｓ１３内の各々で構成されているが、ステップＳ７乃至Ｓ１３の外側に処理対象フィールドについてのループを出すようにしてもよい。【０１３７】
なお、業務システム分析装置は、コンピュータ装置であって、図６７に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【図１】
2009104276.tif 000003
【図２】
2009104276.tif 000004
【図３】
2009104276.tif 000005
【図４】
2009104276.tif 000006
【図５】
2009104276.tif 000007
【図６】
2009104276.tif 000008
【図７】
2009104276.tif 000009
【図８】
2009104276.tif 000010
【図９】
2009104276.tif 000011
【図１０】
2009104276.tif 000012
【図１１】
2009104276.tif 000013
【図１２】
2009104276.tif 000014
【図１３】
2009104276.tif 000015
【図１４】
2009104276.tif 000016
【図１５】
2009104276.tif 000017
【図１６】
2009104276.tif 000018
【図１７】
2009104276.tif 000019
【図１８】
2009104276.tif 000020
【図１９】
2009104276.tif 000021
【図２０】
2009104276.tif 000022
【図２１】
2009104276.tif 000023
【図２２】
2009104276.tif 000024
【図２３】
2009104276.tif 000025
【図２４】
2009104276.tif 000026
【図２５】
2009104276.tif 000027
【図２６】
2009104276.tif 000028
【図２７】
2009104276.tif 000029
【図２８】
2009104276.tif 000030
【図２９】
2009104276.tif 000031
【図３０】
2009104276.tif 000032
【図３１】
2009104276.tif 000033
【図３２】
2009104276.tif 000034
【図３３】
2009104276.tif 000035
【図３４】
2009104276.tif 000036
【図３５】
2009104276.tif 000037
【図３６】
2009104276.tif 000038
【図３７】
2009104276.tif 000039
【図３８】
2009104276.tif 000040
【図３９】
2009104276.tif 000041
【図４０】
2009104276.tif 000042
【図４１】
2009104276.tif 000043
【図４２】
2009104276.tif 000044
【図４３】
2009104276.tif 000045
【図４４】
2009104276.tif 000046
【図４５】
2009104276.tif 000047
【図４６】
2009104276.tif 000048
【図４７】
2009104276.tif 000049
【図４８】
2009104276.tif 000050
【図４９】
2009104276.tif 000051
【図５０】
2009104276.tif 000052
【図５１】
2009104276.tif 000053
【図５２】
2009104276.tif 000054
【図５３】
2009104276.tif 000055
【図５４Ａ】
2009104276.tif 000056
【図５４Ｂ】
2009104276.tif 000057
【図５５】
2009104276.tif 000058
【図５６】
2009104276.tif 000059
【図５７】
2009104276.tif 000060
【図５８Ａ】
2009104276.tif 000061
【図５８Ｂ】
2009104276.tif 000062
【図５９】
2009104276.tif 000063
【図６０】
2009104276.tif 000064
【図６１】
2009104276.tif 000065
【図６２】
2009104276.tif 000066
【図６３】
2009104276.tif 000067
【図６４】
2009104276.tif 000068
【図６５】
2009104276.tif 000069
【図６６】
2009104276.tif 000070
【図６７】
2009104276.tif 000071
【手続補正書】
【提出日】平成22年7月26日(2010.7.26)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務プロセス分析のための情報処理技術に関する。
【背景技術】
【０００２】
業務プロセス・リエンジニアリング（ＢＰＲ：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という流れと基本として、回収というイベントインスタンスが１回繰り返されるプロセスインスタンスが２つと、回収というイベントインスタンスが２回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが３回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが４回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが５回繰り返されるプロセスインスタンスが１つ生成されている。残りのプロセスインスタンスについても、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という遷移が行われるプロセスインスタンスが１つ含まれるグループとに分類される。従って、モデルデータ格納部２３には、図６３に示すようなデータが格納される。図６３の例では、上で述べた３つのグループのプロセスインスタンスと、それぞれの計数値が登録されている。なお、主要フローフラグの欄には、この段階では何も登録されない。
【０１２３】
そして、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、フロー表示処理を実施する（ステップＳ２５）。フロー表示処理について図６４乃至図６６を用いて説明する。
【０１２４】
まず、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているプロセスインスタンスのグループを計数値に基づき降順に整列させる（ステップＳ１４１）。そして、各プロセスのグループを主要フローとして扱うための判断基準となる、当該グループのプロセスインスタンスの総数に占める比率の閾値を、ユーザから入力された場合には当該入力値により、ユーザの入力がない場合には予め設定されている値で決定する（ステップＳ１４３）。例えば総数に占める比率の閾値２０％以上のグループを主要フローと分類する場合には、２０％を入力する。但し、予め設定されている値（例えば３０％）をそのまま用いるようにしても良い。
【０１２５】
そして、プロセス表示処理部２５は、計数値上位より１つ未選択のプロセスインスタンスのグループを選択する（ステップＳ１４７）。この選択されたグループのプロセスを主要フロー（典型フローとも呼ぶ）に指定する（ステップＳ１４９）。具体的には、モデルデータ格納部２３のテーブルにおける主要フローフラグをオンにセットする。また、計数値から全体に対する比率を計算する（ステップS１５１）。そして、選択グループの全体に対して占める比率≧閾値であるか判断する（ステップＳ１５３）。この条件が満たされている場合にはステップＳ１４７に戻る。
【０１２６】
例えば、図６３の例では、最初に第１レコードを選択すると、全体に占める比率が６０％となり、閾値が２０％であれば、ステップＳ１４７に戻る。次に、第２レコードを選択すると、全体に占める比率は３０％となり、同様に、ステップＳ１４７に戻る。このように第１レコード及び第２レコードについて主要フローフラグがオンにセットされる。
【０１２７】
最後に、第３レコードを選択すると、全体に占める比率が１０％となり、全体に占める比率≧閾値という条件が満たされなくなるので、元の処理に戻る。このようにすれば、ステップＳ１４７で選択されたグループ以外のプロセスインスタンスは、主要フローフラグがオンにセットされていないので、例外フローとして特定されたことになる。
【０１２８】
図３の説明に戻って、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、入出力部１１を介して処理結果を出力する（ステップＳ２７）。例えば、全てのプロセスインスタンスを重ね合わせて表示する場合には、図６５に示すような業務フローが表示されるようになる。図６５で示すように、継続を経由する手戻りと契約更新を経由する手戻りと、回収の繰り返しがそれぞれ１つだけ存在するような表示になる。
【０１２９】
また、モデルデータ格納部２３に格納されている主要フローフラグのデータを用いて、主要フローと例外フローとを分けて表示する場合には、図６６に示すような表示がなされる。例えば、９０％を分類割合としていると、図６３に示したテーブルにおいて第１及び第２レコードのプロセスインスタンスが重ね合わされて、図６６の上段のような業務フローが主要フローとして表示される。また、図６３に示したテーブルにおいて第３のプロセスインスタンスが、例外フローとして表示される。
【０１３０】
このような処理を実施すれば、図５２のような分類及び表示と比べて、非常に整理された形で業務フローが提示されるため、ユーザは、実際に実施されている業務フローの概要をより把握しやすくなる。すなわち、特徴を把握する上で業務の全体像の把握を困難にしている手戻りや繰り返しが省略されているので、繰り返しの有無や仕方、手戻りの有無や仕方を、把握しやすくなる。
【０１３１】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、例えば図１に示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュールに対応しない。
【０１３２】
また、業務の全体像の把握を困難にしている手戻りを削除してプロセスインスタンスを再構築する際には、図５９に示すように手戻りが１箇所に複数存在する場合には、その順番を一定のルールで定めておかないと異なるプロセスインスタンスとして認識されてしまう。例えば、手戻りの長さが短い順に並べてからプロセスインスタンスを再構築するというルールを採用すれば、手戻りの順番が異なる実質的に同じプロセスインスタンスが生成されることが無くなる。
【０１３３】
また、各スコア表も一例であって、確度スコア値の設定の仕方は、経験的にさらに細かく決定される場合もある。さらに、スコア表の項目についても、より少ない項目が設定される場合もあれば、より多くの項目が設定される場合もある。
【０１３４】
また、図３の処理フローにおいて、ステップＳ７乃至Ｓ１３については順番の入れ替えが可能であり、また並列に実施するようにしてもよい。
【０１３５】
また、判定結果の出力では、各判定項目において「確定」判定や所定の閾値以上の確度スコアとなっているフィールドを自動的に選択してユーザに提示し、自動選択できない判定項目についてユーザに選択又は入力を促すようにしてもよい。
【０１３６】
さらに、処理対象フィールドについてのループは、ステップＳ７乃至Ｓ１３内の各々で構成されているが、ステップＳ７乃至Ｓ１３の外側に処理対象フィールドについてのループを出すようにしてもよい。
【０１３７】
なお、業務システム分析装置は、コンピュータ装置であって、図６７に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図１０
【補正方法】変更
【補正の内容】
【図１０】
2009104276.tif 000072
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図３５
【補正方法】変更
【補正の内容】
【図３５】
2009104276.tif 000073
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図６４
【補正方法】変更
【補正の内容】
【図６４】
2009104276.tif 000074
【手続補正５】
【補正対象書類名】図面
【補正対象項目名】図６６
【補正方法】変更
【補正の内容】
【図６６】
2009104276.tif 000075
【国際調査報告】
2009104276.tif 000076
2009104276.tif 000077
2009104276.tif 000078
2009104276.tif 000079