JP4832523B2 - 業務プロセス分析のための情報処理方法及び装置 - Google Patents

Description

本発明は、業務プロセス分析のためのデータ生成技術に関する。

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

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

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

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

しかしながら、業務システムに改変を加えたり、業務実行に不要な負荷を与えることは、現在使用中の業務システムに悪影響を及ぼすため、たとえＢＰＲのためといっても避けるべきである。

従って、本発明の目的は、現在使用中の業務システムに悪影響を及ぼすことなく、業務プロセス分析のためのデータを生成するための技術を提供することである。

本発明の第１の態様に係る、業務プロセス分析のための情報処理方法は、解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定するステップと、データ格納部に格納されている、レコードにおける各フィールドの定義データを用いて、当該処理対象フィールドがイベントのタイムスタンプである蓋然性を表すデータを特定する蓋然性データ特定ステップとを含む。

業務システムに悪影響を与えることなく既に存在するデータから、イベントのタイムスタンプ、すなわちイベントの発生日時について可能性を表すデータ（例えば、確度やＡ、Ｂ、Ｃといったランク付け）を特定することができるようになる。すなわち、業務プロセス分析に必要なイベントに関するデータを特定できるようになる。

なお、上で述べた定義データが、データベースのスキーマ情報である場合もある。その場合、上で述べた蓋然性データ特定ステップが、スキーマ情報から、処理対象フィールドのデータ型を特定するステップと、処理対象フィールドのデータ型が、タイムスタンプを表すデータ型であるか判断するステップとを含むようにしてもよい。

また、上で述べた定義データが、フィールド名を含む場合もある。その場合、上で述べた蓋然性データ特定ステップが、処理対象フィールドのフィールド名に含まれる文字列に基づき、イベントのタイムスタンプである蓋然性を表すデータを特定するステップを含むようにしてもよい。定義データは、スキーマ情報の場合もあれば、ＣＳＶ（Comma Separated Values）データのラベルデータであってもよい。例えば、タイムスタンプであればフィールド名の末尾などに特徴を有するためである。

さらに、上で述べた蓋然性データ特定ステップが、処理対象フィールドのフィールド値に基づき、イベントのタイムスタンプである蓋然性を表すデータを特定するステップを含むようにしてもよい。タイムスタンプであるフィールド値の形式は、例えばＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓといった特徴のある文字列の形式を有するためである。

さらに、処理対象フィールドのフィールド名に含まれる文字列について、時刻を表す文字列、日を表す文字列、将来の時期を表す文字列の順番にてより低い上記蓋然性を表すデータが特定されるようにしてもよい。将来の時刻を表す文字列は、例えば納期、予定といった文字列であって、イベントの発生日時を特定する目的においてはタイムスタンプである蓋然性は低く判断されるものである。

また、上で述べた蓋然性データ特定ステップが、データ格納部に格納されている、レコードにおける各フィールドの定義データ及びフィールド値から、処理対象フィールドの該当データを特定するステップと、予め定められた、フィールド名又はフィールド値の特性と対応する蓋然性を表すデータとを格納するスコア表を参照して、処理対象フィールドの該当データに対応する上記蓋然性を表すデータを特定するステップとを含む。スコア表において上記蓋然性を表すデータは具体的な数値の場合もあるが、所定のレベル分けに従ってレベルを特定するようにしてもよい。

なお、本発明の第１の態様においては、イベントのタイムスタンプである蓋然性を表すデータを、各フィールドに対応させてユーザに提示するステップをさらに含むようにしてもよい。この提示によって、ユーザはいずれのフィールドをイベントのタイムスタンプのフィールドであるかを最終的に特定するようにしてもよい。この場合、イベントのタイムスタンプであるフィールドのフィールド値を収集して、後の処理に利用するようにしてもよい。なお、最も蓋然性の高いフィールドを自動的に抽出して、当該フィールド名又はフィールド値若しくはその両方を提示するようにしてもよい。さらに、イベントのタイムスタンプは、他の手法で特定されるイベント名、イベントＩＤ、存在する場合には関連ＩＤなどと共にイベント候補データとしてイベント候補データ格納部に格納される場合もある。また、イベント候補データからＩＤ間の関連付けが行われてイベントデータが生成され、イベントデータ格納部に格納される場合もある。

本発明の第２の態様に係る、業務プロセス分析のための情報処理方法は、解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定するステップと、データ格納部に格納されている、処理対象フィールドのフィールド値の特性を特定するステップと、処理対象フィールドのフィールド値の特性が予め定められた特性を有するか否かに基づき、当該処理対象フィールドがイベントのイベントＩＤである蓋然性を表すデータを特定するステップとを含む。

業務システムに悪影響を与えることなく既に存在するデータから、イベントのイベントＩＤ、すなわちイベントの識別データについて可能性を表すデータ（例えば、確度やＡ、Ｂ、Ｃといったランク付け）を特定することができるようになる。すなわち、業務プロセス分析に必要なイベントに関するデータを特定できるようになる。

また、本発明の第２の態様において、イベントのイベントＩＤである蓋然性を表すデータが否定を表すデータでない場合、データ格納部に格納されている、レコードにおける各フィールドの定義データを用いて、当該処理対象フィールドがイベントのイベントＩＤである蓋然性を表すデータを特定する第２蓋然性データ特定ステップをさらに含むようにしてもよい。例えば処理対象フィールドのフィールド値の特性が予め定められた特性を有しない場合には、フィールドの定義データに基づきさらに判断するものである。

なお、上で述べた定義データが、各フィールドのデータ型のデータを含む場合もある。また、上で述べた定義データが、キー設定データを含む場合もある。スキーマ情報を入手できる場合には、例えば主キーであるか否かについてのデータも含まれるので、当該データを用いればよい。

また、上で述べた第２蓋然性データ特定ステップが、データ格納部に格納されている、レコードにおける各フィールドの定義データから、処理対象フィールドの該当データを特定するステップと、予め定められた、フィールドのデータ型又はフィールドの特性と対応する蓋然性を表すデータとを格納するスコア表を参照して、処理対象フィールドの該当データに対応する蓋然性を表すデータを特定するステップとを含むようにしてもよい。スコア表において上記蓋然性を表すデータは具体的な数値の場合もあるが、所定のレベル分けに従ってレベルを特定するようにしてもよい。また、スコア表に該当する項目がない場合には、予め定められた値を設定するようにしてもよい。

さらに、本発明の第２の態様においては、イベントのイベントＩＤである蓋然性を表すデータを、各フィールドに対応させてユーザに提示するステップをさらに含むようにしてもよい。この提示によって、ユーザはいずれのフィールドをイベントのイベントＩＤのフィールドであるかを最終的に特定するようにしてもよい。この場合、イベントのイベントＩＤであるフィールドのフィールド値を収集して、後の処理に利用するようにしてもよい。なお、最も蓋然性の高いフィールドを自動的に抽出して、当該フィールド名又はフィールド値若しくはその両方を提示するようにしてもよい。さらに、イベントＩＤは、他の手法で特定されるイベント名、タイムスタンプ、存在する場合には関連ＩＤなどと共にイベント候補データとしてイベント候補データ格納部に格納される場合もある。また、イベント候補データからＩＤ間の関連付けが行われてイベントデータが生成され、イベントデータ格納部に格納される場合もある。

さらに、上で述べた第１蓋然性データ特定ステップが、処理対象フィールドのフィールド値が全てのレコードで一意であるか否かを判断するステップと、処理対象フィールドのフィールド値にＮＵＬＬが含まれているか判断するステップとを含むようにしてもよい。イベントＩＤのフィールド値の特性として、フィールド値が全てのレコードで一意であり、ＮＵＬＬが含まれないという特性があるためである。

本発明の第３の態様に係る、業務プロセス分析のための情報処理方法は、解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定するステップと、データ格納部に格納されている、処理対象フィールドのフィールド値の特性を特定するステップと、処理対象フィールドのフィールド値の特性が予め定められた特性を有するか否かに基づき、当該処理対象フィールドがイベントの関連ＩＤである蓋然性を表すデータを特定するステップとを含む。

業務システムに悪影響を与えることなく既に存在するデータから、イベントの関連ＩＤ、すなわちイベントＩＤに関連するＩＤである可能性を表すデータ（例えば、確度やＡ、Ｂ、Ｃといったランク付け）を特定することができるようになる。すなわち、業務プロセス分析に必要なイベントに関するデータを特定できるようになる。

また、イベントの関連ＩＤである蓋然性を表すデータが否定を表すデータでない場合、データ格納部に格納されている、レコードにおける各フィールドの定義データを用いて、当該処理対象フィールドがイベントの関連ＩＤである蓋然性を表すデータを特定する第２蓋然性データ特定ステップをさらに含むようにしてもよい。例えば処理対象フィールドのフィールド値の特性が予め定められた特性を有しない場合には、フィールドの定義データに基づきさらに判断するものである。

なお、上で述べた定義データが、各フィールドのデータ型のデータを含む場合もある。また、上で述べた定義データが、キー設定データを含む場合もある。スキーマ情報を入手することができ、例えば副キーという指定があればそれを用いることができる。

また、上で述べた第２蓋然性データ特定ステップが、データ格納部に格納されている、レコードにおける各フィールドの定義データから、処理対象フィールドの該当データを特定するステップと、予め定められた、フィールドのデータ型又はフィールドの特性と対応する蓋然性を表すデータとを格納するスコア表を参照して、処理対象フィールドの該当データに対応する上記蓋然性を表すデータを特定するステップとを含むようにしてもよい。スコア表において上記蓋然性を表すデータは具体的な数値の場合もあるが、その数値を所定のレベル分けに従ってレベルを特定するようにしてもよい。また、スコア表に該当する項目がない場合には、予め定められた値又はレベルを設定するようにしてもよい。また、複数の項目に該当する場合には、例えば高い値を有する項目又は中央値からはずれた値を採用するようにしてもよい。

さらに、本発明の第３の態様においては、イベントの関連ＩＤである蓋然性を表すデータを、各フィールドに対応させてユーザに提示するステップをさらに含むようにしてもよい。この提示によって、ユーザはいずれのフィールドをイベントの関連ＩＤのフィールドであるかを最終的に特定するようにしてもよい。この場合、イベントの関連ＩＤであるフィールドのフィールド値を収集して、後の処理に利用するようにしてもよい。なお、最も蓋然性の高いフィールドを自動的に抽出して、当該フィールド名又はフィールド値若しくはその両方を提示するようにしてもよい。さらに、他の手法で特定されるイベント名、タイムスタンプ、イベントＩＤなどと共にイベント候補データとしてイベント候補データ格納部に格納される場合もある。また、イベント候補データからＩＤ間の関連付けが行われてイベントデータが生成され、イベントデータ格納部に格納される場合もある。

さらに、上で述べた第１蓋然性データ特定ステップが、処理対象フィールドのフィールド値がＮＵＬＬを除き２以上の値を有するか判断するステップを含むようにしてもよい。関連ＩＤの場合、フィールド値はＮＵＬＬを除き２以上の値を有するためである。

本発明の第４の態様に係る業務プロセス分析のための情報処理方法は、解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける各フィールドについて、データ格納部に格納されている、レコードにおける各フィールドの定義データを用いて、当該フィールドがイベントのタイムスタンプである蓋然性を表すデータを特定するステップと、イベントのタイムスタンプである蓋然性を表すデータが所定のデータであるフィールド又はイベントのタイムスタンプである蓋然性を表すデータに基づきユーザによってタイムスタンプであると指定されたフィールドを特定するステップと、特定されたフィールドの数に基づき、イベント名を特定するイベント名特定ステップとを含む。

このようにタイムスタンプとみなされるフィールドの数によって元のテーブルの性質が定まるため、イベント名をも特定することができるようになる。

例えば、上で述べたイベント名特定ステップが、フィールドの数が単数である場合には、テーブル名をイベント名として特定するステップを含むようにしてもよい。例えば受注ＤＢであれば、イベント名は「受注」となる。

また、上で述べたイベント名特定ステップが、フィールドの数が複数である場合には、特定された上記フィールドのフィールド名に基づきイベント名を特定するステップを含むようにしてもよい。例えば、１レコードに複数のイベントを含むようなテーブルの場合、受注日時、起票日時、納品日時、検品日時などのタイムスタンプが存在する。このような場合には、「受注」「起票」「納品」「検品」といったイベント名を特定する。

なお、本発明の第４の態様においては、データ格納部に格納されている、各フィールドのフィールド値の特性を特定するステップと、各フィールドのフィールド値の特性が予め定められた特性を有するか否かに基づき、当該フィールドがイベントのイベントＩＤである蓋然性を表すデータを特定するステップと、イベントのイベントＩＤである蓋然性を表すデータが否定を表すデータでない場合、データ格納部に格納されている、レコードにおける各フィールドの定義データを用いて、当該フィールドがイベントのイベントＩＤである蓋然性を表すデータを特定するステップとをさらに含むようにしてもよい。これによって、イベントＩＤをも特定することができるようになる。

さらに、本発明の第４の態様において、フィールドのフィールド値の特性が予め定められた第２の特性を有するか否かに基づき、当該フィールドがイベントの関連ＩＤである蓋然性を表すデータを特定するステップと、イベントの関連ＩＤである蓋然性を表すデータが否定を表すデータでない場合、データ格納部に格納されている、レコードにおける各フィールドの定義データを用いて、当該フィールドがイベントの関連ＩＤである蓋然性を表すデータを特定するステップとをさらに含むようにしてもよい。これによって、さらに関連ＩＤをも特定することができるようになる。
なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

図１は、本発明の実施の形態における業務システム分析装置の機能ブロック図である。 図２（ａ）乃至（ｄ）は、本発明の実施の形態の概要を説明するための図である。 図３は、本発明の実施の形態におけるメインの処理フローを示す図である。 図４（ａ）は、受注ＤＢのスキーマ情報、図４（ｂ）は、受注ＤＢのレコード群を示す図である。 図５（ａ）は、生産ＤＢのスキーマ情報、図５（ｂ）は、生産ＤＢのレコード群を示す図である。 図６（ａ）は、手配ＤＢのスキーマ情報、図６（ｂ）は、手配ＤＢのレコード群を示す図である。 図７（ａ）は、配送ＤＢのスキーマ情報、図７（ｂ）は、配送ＤＢのレコード群を示す図である。 図８（ａ）は、品番ＤＢのスキーマ情報、図８（ｂ）は、品番ＤＢのレコード群を示す図である。 図９（ａ）は、ＣＳＶ形式の受注ＤＢのデータ例を示し、図９（ｂ）は、受注ＤＢのデータをテーブル化した例を示す図である。 図１０（ａ）は、ＣＳＶ形式の生産ＤＢのデータ例を示し、図１０（ｂ）は、生産ＤＢのデータをテーブル化した例を示す図である。 図１１（ａ）は、ＣＳＶ形式の手配ＤＢのデータ例を示し、図１１（ｂ）は、手配ＤＢのデータをテーブル化した例を示す図である。 図１２（ａ）は、ＣＳＶ形式の配送ＤＢのデータ例を示し、図１２（ｂ）は、配送ＤＢのデータをテーブル化した例を示す図である。 図１３（ａ）は、ＣＳＶ形式の品番ＤＢのデータ例を示し、図１３（ｂ）は、品番ＤＢのデータをテーブル化した例を示す図である。 図１４は、タイムスタンプ判定処理の処理フローを示す図である。 図１５は、タイムスタンプ確度スコア表の一例を示す図である。 図１６は、イベントＩＤ及び関連ＩＤ候補判定処理の処理フローを示す図である。 図１７は、イベントＩＤ・関連ＩＤ候補確度スコア表の一例を示す図である。 図１８は、イベント名判定処理の処理フローを示す図である。 図１９は、タイムスタンプが複数含まれるテーブルの一例を示す図である。 図２０（ａ）乃至（ｅ）は、図１９を構成する元のテーブルの一例を示す図である。 図２１は、スキーマ情報が存在する場合における、受注ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２２は、ＣＳＶ形式のデータの場合における、受注ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２３は、スキーマ情報が存在する場合における、生産ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２４は、ＣＳＶ形式のデータの場合における、生産ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２５は、スキーマ情報が存在する場合における、手配ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２６は、ＣＳＶ形式のデータの場合における、手配ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２７は、スキーマ情報が存在する場合における、配送ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２８は、ＣＳＶ形式のデータの場合における、配送ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２９は、スキーマ情報が存在する場合における、品番ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図３０は、ＣＳＶ形式のデータの場合における、品番ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図３１は、イベント候補データの各要素に対する選択結果の一例を示す図である。 図３２は、スキーマ情報が存在する場合において受注ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３３は、ＣＳＶ形式のデータの場合において受注ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３４は、スキーマ情報が存在する場合において生産ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３５は、ＣＳＶ形式のデータの場合において生産ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３６は、スキーマ情報が存在する場合において手配ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３７は、ＣＳＶ形式のデータの場合において手配ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３８は、スキーマ情報が存在する場合において配送ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３９は、ＣＳＶ形式のデータの場合において配送ＤＢのデータから生成したイベント候補データの一例を示す図である。 図４０は、図１９の起票に関するイベント候補データの一例を示す図である。 図４１は、図１９の承認に関するイベント候補データの一例を示す図である。 図４２は、図１９の発注に関するイベント候補データの一例を示す図である。 図４３は、図１９の納品に関するイベント候補データの一例を示す図である。 図４４は、図１９の検収に関するイベント候補データの一例を示す図である。 図４５は、イベントデータ及びイベント間関係ツリーの一例を示す図である。 図４６は、イベントデータからのプロセスインスタンス生成を説明するための図である。 図４７は、プロセスインスタンスの一例を示す図である。 図４８は、プロセスフロー分析結果の表示例を示す図である。 図４９は、プロセスフロー分析結果の他の表示例を示す図である。 図５０は、本発明の実施の形態におけるメインの処理フローの他の例を示す図である。 図５１は、コンピュータ装置の機能ブロック図である。

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

なお、入出力部１１は、イベント候補データ生成部３、プロセスインスタンス生成部１３、プロセスフロー生成部１７及びプロセス分析部２１についても、ユーザとのインターフェースとして動作する。また、各処理部は、処理結果などを読み出して入出力部１１を介してユーザに提示するなどの処理も実施することもある。但し、イベントデータからプロセスフローデータを生成する処理は自動的に行われる場合もあり、この場合には、プロセスインスタンス生成部１３及びプロセスフロー生成部１７については、各処理結果の中間結果表示を行う場合を除き、インターフェースは不要である。

また、本実施の形態における主要構成部分であるイベント候補データ生成部３は、タイムスタンプ処理部３１と、イベントＩＤ・関連ＩＤ候補処理部３２と、イベント名処理部３４と、スコア表格納部３５とを有する。

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

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

その後、プロセスインスタンス生成部１３は、イベントデータ格納部９に格納されているイベントデータからプロセスインスタンスのデータを生成する。プロセスインスタンスの一例を図２（ｃ）に示す。図２（ｃ）の例では、４つのプロセスインスタンスが例示されており、各々のプロセスインスタンスには、一連のイベントインスタンス（具体的なイベント）が含まれている。すなわち、例えば「受注」「起票」「納品」「検品」といったイベントクラスに属する連続するイベントインスタンス（具体的なイベントであり特定のレコードに対応するイベント）でプロセスインスタンスが構成される。ただし、プロセスインスタンスに含まれるイベントインスタンスは、すべてのイベントクラスに由来する必要はなく、ひとつのイベントクラスに属するイベントインスタンスが複数含まれていても良い。

そして、プロセスフロー生成部１７は、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスのデータからプロセスフローのデータを生成する。プロセスフローの一例を図２（ｄ）に示す。図２（ｄ）の例では、プロセスインスタンスが抽象化されて特定される業務フローが示されている。図２（ｃ）及び（ｄ）のデータを生成する処理自体は、本実施の形態における主要部ではなく、例えば日本国の特願２００６−１３６５１８号（２００６年５月１６日出願）及びその対応外国出願に開示されている。

さらに、プロセス分析部２１は、プロセスフローデータ格納部１９に格納されているプロセスフローのデータに対して各種分析処理を実施する。プロセスフローに対する分析処理については、本実施の形態における主要部ではなく、様々な分析処理が存在しており、ここではその詳細については省略する。なお、分析処理についても、例えば日本国の特願２００６−１３６５１８号（２００６年５月１６日出願）及びその対応外国出願に開示されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このようにして以下の処理で用いるイベント候補データがイベント候補データ格納部５に格納されるようになる。以上が本実施の形態の主要部である。なお、以下は後処理となる。後処理については人間が手動で行うようにしてもよい。

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

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

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

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

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

同様にして、図４５のイベントデータを用いて、生成した全プロセスインスタンスを図４７に示す。

さらに、プロセスフロー生成部１７は、プロセスインスタンスデータ格納部１５に格納されているデータを用いてプロセスフロー生成処理を実施し、処理結果をプロセスフローデータ格納部１９に格納する（ステップＳ２１）。その生成方法としては、上で述べた特願２００６−１３６５１８記載のような業務モデル生成プログラムの処理方法等を用いることができる。

図４７の全プロセスインスタンスを重ね合わせて生成したプロセスフローを図４８に示す。図の丸はイベントクラス（すなわち、イベントの種類）を示し、矢印は業務プロセスの中で発生したイベント間の遷移を示す。

最後に、プロセス分析部２１は、プロセスフローデータ格納部１９に格納されているデータを用いてプロセス分析処理を実施し、処理結果を分析結果格納部２３に格納する（ステップＳ２３）。その分析方法としては、上で述べた特願２００６−１３６５１８記載のような業務モデル生成プログラムの分析方法等を用いることができる。

図４７の全プロセスインスタンスを元に、業務プロセスの分析を行った例を図４９に示す。出現頻度が高いプロセスインスタンスの上位から５０％の重ね合わせ即ち、図４７のプロセスインスタンスの２番目と３番目を重ね合わせることで、解析対象の業務プロセスの主要フローの分析のための表示を行うことができる。また、その主要フロー表示に、例外フローとして、図４７のプロセスインスタンスの１番目を重ね合わせることによって、想定外のイベント間の遷移を発見するための表示を行うことができる。図４９の表示からは、配送イベントから生産イベントへの手戻り発生を疑わせるイベント間の遷移を発見することができる。

以上のような処理を実施し、入出力部１１は、各処理部の処理結果をユーザに対して提示する（ステップＳ２５）。

このような処理を実施することによって、ユーザは、業務システムに手を加えることなく、その業務システムのデータをコピーするだけで業務プロセスの分析を実施できるようになる。また、業務システムのデータは、ＲＤＢであってもＣＳＶであってもよい。さらに他の形式であっても、上で述べたような技術思想に基づき対処可能である。

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

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

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

図３の変形例を図５０に示す。まず、ユーザは、業務システムにおける解析対象テーブルの指定を行い、そのデータをコピーして分析対象データ格納部１に格納させる（図５０：ステップＳ１１１）。ユーザの動作であるから図５０においては点線ブロックで表されている。次に、例えばイベント候補データ生成部３は、全ての解析対象テーブルについて処理したか判断する（ステップＳ１１３）。

未処理の解析対象テーブルが存在する場合には、例えばイベント候補データ生成部３は、未処理の解析対象テーブルを特定する（ステップＳ１１５）。そして、タイムスタンプ処理部３１は、タイムスタンプ判定処理を実施する（ステップＳ１１７）。この処理は図１４の処理フローと同様である。さらに、イベント名処理部３４は、イベント名判定処理を実施する（ステップＳ１１９）。この処理も図１８の処理フローと同じである。このように本実施の形態では、イベント名判定処理の実施タイミングを繰り上げている。

その後、イベントＩＤ・関連ＩＤ候補処理部３２は、イベントＩＤ及び関連ＩＤ候補判定処理を実施する（ステップＳ１２１）。この処理も図１６の処理フローと同様である。

そして、イベント候補データ生成部３は、入出力部１１を介してステップＳ１１７乃至Ｓ１２１の判定結果をユーザに提示する（ステップＳ１２５）。提示する内容についても、上で述べた例と同様である。ステップＳ１２５が終了すると、ユーザは、入出力部１１を介して、イベント名、タイムスタンプ、イベントＩＤ・関連ＩＤ候補などについて修正入力又は確定入力を行い、レコードのコピーなどを行って又は命じて、イベント候補データを生成し、イベント候補データ生成部３にイベント候補データ格納部５へ格納させる（ステップＳ１２７）。この作業は主に又は一部ユーザによって実施されるので、図５０では点線ブロックで描かれている。そして処理はステップＳ１１３に戻る。

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

また、プロセスインスタンス生成部１３は、イベントデータ格納部９に格納されているイベントデータを用いてプロセスインスタンス生成処理を実施し、処理結果をプロセスインスタンスデータ格納部１５に格納する（ステップＳ１３１）。

さらに、プロセスフロー生成部１７は、プロセスインスタンスデータ格納部１５に格納されているデータを用いてプロセスフロー生成処理を実施し、処理結果をプロセスフローデータ格納部１９に格納する（ステップＳ１３３）。

最後に、プロセス分析部２１は、プロセスフローデータ格納部１９に格納されているデータを用いてプロセス分析処理を実施し、処理結果を分析結果格納部２３に格納する（ステップＳ１３５）。

以上のような処理を実施し、入出力部１１は、各処理部の処理結果をユーザに対して提示する（ステップＳ１３７）。

このような処理を実施することによって、ユーザは、業務システムに手を加えることなく、本来業務のためのデータ処理の結果及び運用管理のために記録しているデータを業務システムから収集するだけで業務プロセスの分析を実施できるようになる。また、業務システムのデータは、ＲＤＢであってもＣＳＶであってもよい。さらに他の形式であっても、上で述べたような思想に基づき対処可能である。

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

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

さらに、図３の場合も図５０の場合も、自動的にイベント候補データからイベントデータを生成するのではなく（すなわちステップＳ１７又はステップＳ１２９を実施するのではなく）、ユーザが例えばステップＳ１５又はＳ１２５の出力をベースに検討して、ステップＳ１６又はＳ１２７において、イベント候補データを経ずにイベントデータを生成するようにしてもよい。すなわち、ＩＤ間の関連付けまでユーザが自らのスキルをもって指定入力して、当該データをイベントデータ格納部９に格納するようにしてもよい。

以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば図１に示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュールに対応しない。また、各スコア表も一例であって、確度スコア値の設定の仕方は、経験的にさらに細かく決定される場合もある。さらに、スコア表の項目についても、より少ない項目が設定される場合もあれば、より多くの項目が設定される場合もある。

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

Claims (8)

1. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定するステップと、
   前記処理対象フィールドがイベントのタイムスタンプである蓋然性を表す確度スコアを特定する蓋然性データ特定ステップと、
   を含み、コンピュータに実行され、
   前記蓋然性データ特定ステップが、
   フィールドのフィールド値が有する特性と、当該特性を有するフィールド値を含むフィールドがイベントのタイムスタンプである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのフィールド値が有する特性に対応する確度スコアを特定する、
   情報処理方法。
2. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定するステップと、
   前記処理対象フィールドのフィールド値が全てのレコードで一意であり、且つ、前記処理対象フィールドのフィールド値にＮＵＬＬが含まれていない場合、当該処理対象フィールドがイベントのイベントＩＤである蓋然性を表す確度スコアを特定する蓋然性データ特定ステップと、
   を含み、コンピュータにより実行され、
   前記蓋然性データ特定ステップが、
   フィールドのデータ型又はフィールドが有する特性と、当該データ型のフィールド又は当該特性を有するフィールドがイベントのイベントＩＤである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのデータ型又は前記処理対象フィールドが有する特性に対応する確度スコアを特定する、
   情報処理方法。
3. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定するステップと、
   前記処理対象フィールドのフィールド値がＮＵＬＬを除いて２以上の値を有する場合、当該処理対象フィールドがイベントの関連ＩＤである蓋然性を表す確度スコアを特定する蓋然性データ特定ステップと、
   を含み、コンピュータにより実行され、
   前記蓋然性データ特定ステップが、
   フィールドのデータ型又はフィールドが有する特性と、当該データ型のフィールド又は当該特性を有するフィールドがイベントの関連ＩＤである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのデータ型又は前記処理対象フィールドが有する特性に対応する確度スコアを特定する、
   情報処理方法。
4. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける各フィールドについて、当該各フィールドがイベントのタイムスタンプである蓋然性を表す確度スコアを特定する蓋然性データ特定ステップと、
   前記イベントのタイムスタンプである蓋然性を表す確度スコアが所定値以上であるフィールド又は前記イベントのタイムスタンプである蓋然性を表す確度スコアに基づきユーザによってタイムスタンプであると指定されたフィールドを特定するステップと、
   特定された前記フィールドの数が単数である場合は、当該フィールドが含まれるテーブル名をイベント名として特定し、複数である場合は、当該フィールドのフィールド名の少なくとも一部の文字列によりイベント名を特定するイベント名特定ステップと、
   を含み、コンピュータにより実行され、
   前記蓋然性データ特定ステップが、
   フィールドのデータ型又はフィールドが有する特性と、当該データ型のフィールド又は当該特性を有するフィールドがイベントのタイムスタンプである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのデータ型又は前記処理対象フィールドが有する特性に対応する確度スコアを特定する、
   情報処理方法。
5. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定する手段と、
   前記処理対象フィールドがイベントのタイムスタンプである蓋然性を表す確度スコアを特定する蓋然性データ特定手段と、
   を有し、
   前記蓋然性データ特定手段が、
   フィールドのフィールド値が有する特性と、当該特性を有するフィールド値を含むフィールドがイベントのタイムスタンプである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのフィールド値が有する特性に対応する確度スコアを特定する、
   情報処理装置。
6. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定する手段と、
   前記処理対象フィールドのフィールド値が全てのレコードで一意であり、且つ、前記処理対象フィールドのフィールド値にＮＵＬＬが含まれていない場合、当該処理対象フィールドがイベントのイベントＩＤである蓋然性を表す確度スコアを特定する蓋然性データ特定手段と、
   を有し、
   前記蓋然性データ特定手段が、
   フィールドのデータ型又はフィールドが有する特性と、当該データ型のフィールド又は当該特性を有するフィールドがイベントのイベントＩＤである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのデータ型又は前記処理対象フィールドが有する特性に対応する確度スコアを特定する、
   情報処理装置。
7. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける処理対象フィールドを特定する手段と、
   前記処理対象フィールドのフィールド値がＮＵＬＬを除いて２以上の値を有する場合、当該処理対象フィールドがイベントの関連ＩＤである蓋然性を表す確度スコアを特定する蓋然性データ特定手段と、
   を有し、
   前記蓋然性データ特定手段が、
   フィールドのデータ型又はフィールドが有する特性と、当該データ型のフィールド又は当該特性を有するフィールドがイベントの関連ＩＤである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのデータ型又は前記処理対象フィールドが有する特性に対応する確度スコアを特定する、
   情報処理装置。
8. 解析対象システムにより生成され且つデータ格納部に格納されているレコードにおける各フィールドについて、当該各フィールドがイベントのタイムスタンプである蓋然性を表す確度スコアを特定する蓋然性データ特定手段と、
   前記イベントのタイムスタンプである蓋然性を表す確度スコアが所定値以上であるフィールド又は前記イベントのタイムスタンプである蓋然性を表す確度スコアに基づきユーザによってタイムスタンプであると指定されたフィールドを特定する手段と、
   特定された前記フィールドの数が単数である場合は、当該フィールドが含まれるテーブル名をイベント名として特定し、複数である場合は、当該フィールドのフィールド名の少なくとも一部の文字列によりイベント名を特定するイベント名特定手段と、
   を有し、
   前記蓋然性データ特定手段が、
   フィールドのデータ型又はフィールドが有する特性と、当該データ型のフィールド又は当該特性を有するフィールドがイベントのタイムスタンプである蓋然性を表す確度スコアとを対応付けて格納する確度スコア表から、前記処理対象フィールドのデータ型又は前記処理対象フィールドが有する特性に対応する確度スコアを特定する、
   情報処理装置。

Images