図1A及び図1Bに、本発明の一実施の形態に係る業務システム分析装置の機能ブロック図を示す。本実施の形態に係る業務システム分析装置は、単数または複数の解析対象システムから収集されたデータ(所定期間において生成されたデータベースのレコード群、ログデータ、ネットワークDB(NDB)のレコード群、ジャーナルなど)を格納する分析対象データ格納部1と、分析対象データ格納部1からイベント候補データを生成するイベント候補データ生成部3と、イベント候補データ生成部3により生成されたイベント候補データを格納するイベント候補データ格納部5と、ユーザとのインターフェースとなる入出力部11と、入出力部11を介してユーザの指示を受け付けイベントデータを生成するイベントデータ生成部7と、イベントデータ生成部7により生成されたイベントデータを格納するイベントデータ格納部9と、イベントデータ格納部9に格納されているイベントデータからプロセスインスタンスを生成するプロセスインスタンス生成部13と、プロセスインスタンス生成部13によって生成されたプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部15と、プロセスインスタンスデータ格納部15に格納されているプロセスインスタンスのデータを用いて並列処理に由来する見かけ上の遷移を検出し、それらを含むプロセスインスタンスを抽出し、該当プロセスインスタンスのフローを見かけ上の遷移を削除した上で推定した並列処理の遷移を追加することで修正する並列処理推定部17と、並列処理推定部17によって修正されたプロセスインスタンス及び並列処理推定部17の処理対象とならなかったプロセスインスタンスのデータを格納する並列処理推定後プロセスインスタンスデータ格納部19と、並列処理推定後プロセスインスタンスデータ格納部19に格納されているプロセスインスタンスをイベントの並び方に基づき分類して発生数をカウントするプロセスインスタンス分類処理部21と、プロセスインスタンス分類処理部21の処理結果を格納するモデルデータ格納部23と、モデルデータ格納部23に格納されているデータを用いて業務フローを表示するために必要な処理を実施するプロセス表示処理部25とを含む。
なお、入出力部11は、イベント候補データ生成部3、プロセスインスタンス生成部13、並列処理推定部17、プロセス表示処理部25についても、ユーザとのインターフェースとして動作する。また、各処理部は、処理結果などを読み出して入出力部11を介してユーザに提示するなどの処理を実施することもある。
また、イベント候補データ生成部3は、タイムスタンプ処理部31と、イベントID・関連ID候補処理部32と、イベント名処理部34と、スコア表格納部35とを有する。
また、図1Bに示すように、並列処理推定部17は、プロセスインスタンスデータ格納部15に格納されているプロセスインスタンスにおけるイベント発生状況から各種統計データを算出する統計情報抽出部171と、統計情報抽出部171によって算出された統計情報を格納する統計情報格納部173と、統計情報格納部173に格納されているデータを用いてプロセスインスタンスデータ格納部15に格納されているプロセスインスタンスの構成要素として存在しているが実際の業務上は発生していないと推定される遷移である見かけ上遷移を検出する見かけ上遷移検出部175と、見かけ上遷移検出部175によって検出された見かけ上遷移を含むプロセスインスタンスを検出して当該プロセスインスタンスにおける見かけ上遷移を削除する見かけ上遷移削除部177と、見かけ上遷移削除部177によって抽出された見かけ上遷移を含むプロセスインスタンスのデータを格納する並列処理該当プロセスインスタンスデータ格納部181と、並列処理該当プロセスインスタンスデータ格納部181に格納されているデータを用いて見かけ上遷移の代わりに設定すべき遷移を特定する代替遷移決定処理部179とを有する。
次に、業務システム分析装置の大まかな処理内容について図2(a)乃至(d)を用いて説明する。まず、イベント候補データ生成部3は、分析対象データ格納部1に格納された業務システムについてのデータからイベント候補データを生成する。イベント候補データの一例を図2(a)に示す。図2(a)の例では、例えば1つのテーブル(例えばデータベース)から、イベント名と、日時(イベントの発生日時であるタイムスタンプ)と、それ以外の第1の値(値1)と、第2の値(値2)などを含むレコード群が抽出されるようになっている。すなわち、イベント名やタイムスタンプ、それ以外にイベントIDや関連IDの候補となるデータ・フィールドが特定される。
次に、イベントデータ生成部7は、イベント候補データ格納部5に格納されているイベント候補データからイベントデータを生成する。イベントデータの一例を図2(b)に示す。図2(b)の例では、複数のテーブル(例えばデータベース)から、イベント名、日時(イベントの発生日時であるタイムスタンプ)、イベントID(ここではID1)及び他の値を含むレコード群と、イベント名、日時(タイムスタンプ)、ID1及びID2などを含むレコード群とが抽出される。そして、第2のイベントクラス(すなわち、イベントの種類)のレコードの関連IDであるID2のフィールド値が、第1のイベントクラス(すなわち、イベントの種類)のレコードのイベントIDであるID1のフィールド値のいずれかの値をとることにより、第2のイベントクラスの各々のレコード(すなわちイベントインスタンス)が、第1のイベントクラスのどのレコード(すなわちイベントインスタンス)と関連しているかが特定される。このようなイベント間の関連などを抽出する処理自体は、本実施の形態における主要部ではなく、例えば特開2008−27072号公報に既に開示されている。
その後、プロセスインスタンス生成部13は、イベントデータ格納部9に格納されているイベントデータからプロセスインスタンスのデータを生成する。プロセスインスタンスの一例を図2(c)に示す。図2(c)の例では、4つのプロセスインスタンスが例示されており、各々のプロセスインスタンスには、一連のイベントインスタンス(具体的なイベント)が含まれている。すなわち、例えば「受注」「起票」「納品」「検品」といったイベントクラスに属する連続するイベントインスタンス(具体的なイベントであり特定のレコードに対応するイベント)でプロセスインスタンスが構成される。ただし、プロセスインスタンスに含まれるイベントインスタンスは、すべてのイベントクラスに由来する必要はなく、ひとつのイベントクラスに属するイベントインスタンスが複数含まれていても良い。なお、プロセスインスタンス生成処理自体は、本実施の形態における主要部ではなく、例えば、米国特許公開公報2005/076059A1のような業務プロセストラッキング方法等を用いることができる。
そして、プロセスインスタンスのデータを、並列処理推定部17及びプロセスインスタンス分類処理部21によって処理をして、プロセス表示処理部25は、モデルデータ格納部23に格納されているデータからプロセスフロー(業務フローとも呼ぶ)のデータを生成して、入出力部11を介して表示装置に表示する。プロセスフローの一例を図2(d)に示す。図2(d)の例では、プロセスインスタンスが集約されて特定される業務フローが示されている。
次に、図1A及び図1Bに示した業務システム分析装置の処理の詳細を図3乃至図77を用いて説明する。まず、ユーザは、業務システムにおける解析対象テーブルの指定を行い、そのデータをコピーして分析対象データ格納部1に格納させる(図3:ステップS1)。例えば、受注DB、生産DB、手配DB、配送DB、品番DBが指定され、所定期間において生成され蓄積されていたレコード群をコピーして、分析対象データ格納部1に格納する。なお、これらのDBがリレーショナルデータベースであれば、スキーマ情報をもコピーして、分析対象データ格納部1に格納しておく。本ステップについては、予めユーザがコンピュータを操作して行う処理であるから、図3では点線ブロックで示している。
例えば受注DBがリレーショナルデータベースである場合には、図4(a)のようなスキーマ情報と図4(b)に示すようなレコード群とが分析対象データ格納部1に格納される。図4(a)に示したスキーマ情報の例では、フィールド1乃至4のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図4(a)から、フィールド1には日時が登録され、フィールド2には主キーである受注番号が登録され、フィールド3には地域が登録され、フィールド4には受注内容が登録されることが分かる。具体的には図4(b)のようなレコード群となるが、図4(a)のようなスキーマ情報を得れば、図4(b)のようなレコード群の内容を容易に解釈することができる。
同様に、生産DBがリレーショナルデータベースである場合には、図5(a)のようなスキーマ情報と図5(b)に示すようなレコード群とが分析対象データ格納部1に格納される。図5(a)に示したスキーマ情報の例では、フィールド1乃至5のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図5(a)から、フィールド1には日時が登録され、フィールド2には主キーである生産番号が登録され、フィールド3には副キーである受注番号が登録され、フィールド4には副キーである品番が登録され、フィールド5には納期が登録されることが分かる。具体的には図5(b)のようなレコード群となるが、図5(a)のようなスキーマ情報を得れば、図5(b)のようなレコード群の内容を容易に解釈することができる。
また、手配DBがリレーショナルデータベースである場合には、図6(a)のようなスキーマ情報と図6(b)に示すようなレコード群とが分析対象データ格納部1に格納される。図6(a)に示したスキーマ情報の例では、フィールド1乃至5のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図6(a)から、フィールド1には日時が登録され、フィールド2には主キーである手配番号が登録され、フィールド3には副キーである受注番号が登録され、フィールド4には副キーである品番が登録され、フィールド5には納品先が登録されることが分かる。具体的には図6(b)のようなレコード群となるが、図6(a)のようなスキーマ情報を得れば、図6(b)のようなレコード群の内容を容易に解釈することができる。
さらに、配送DBがリレーショナルデータベースである場合には、図7(a)のようなスキーマ情報と図7(b)に示すようなレコード群とが分析対象データ格納部1に格納される。図7(a)に示したスキーマ情報の例では、フィールド1乃至4のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図7(a)から、フィールド1には日時が登録され、フィールド2には主キーである手配番号が登録され、フィールド3には副キーである配送便が登録され、フィールド4に納品先が登録されることが分かる。具体的には図7(b)のようなレコード群となるが、図7(a)のようなスキーマ情報を得れば、図7(b)のようなレコード群の内容を容易に解釈することができる。
また、品番DBがリレーショナルデータベースである場合には、図8(a)のようなスキーマ情報と図8(b)に示すようなレコード群とが分析対象データ格納部1に格納される。図8(a)に示したスキーマ情報の例では、フィールド1及び2のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図8(a)から、フィールド1には主キーである品番が登録され、フィールド2には品名が登録されることが分かる。具体的には図8(b)のようなレコード群となるが、図8(a)のようなスキーマ情報を得れば、図8(b)のようなレコード群の内容を容易に解釈することができる。
一方、受注DBのデータをCSV形式で取得した場合には、図9(a)に示すようなデータが分析対象データ格納部1に格納される。図9(a)の例では、日時、受注番号、地域及び受注内容というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図9(a)をわかりやすくするためにテーブル形式にすると図9(b)に示すようになる。すなわち、日時の列と、受注番号の列と、地域の列と、受注内容の列とを含むテーブルとなる。スキーマ情報はないので、データは皆文字列として格納される。また、キー設定データはない。
同様に、生産DBのデータをCSV形式で取得した場合には、図10(a)に示すようなデータが分析対象データ格納部1に格納される。図10(a)の例では、日時、生産番号、受注番号、品番及び納期というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図10(a)をわかりやすくするためにテーブル形式にすると図10(b)に示すようになる。すなわち、日時の列と、生産番号の列と、受注番号の列と、品番の列と、納期の列とを含むテーブルとなる。
また、手配DBのデータをCSV形式で取得した場合には、図11(a)に示すようなデータが分析対象データ格納部1に格納される。図11(a)の例では、日時、手配番号、受注番号、品番及び納品先というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図11(a)をわかりやすくするためにテーブル形式にすると図11(b)に示すようになる。すなわち、日時の列と、手配番号の列と、受注番号の列と、品番の列と、納品先の列とを含むテーブルとなる。
さらに、配送DBのデータをCSV形式で取得した場合には、図12(a)に示すようなデータが分析対象データ格納部1に格納される。図12(a)の例では、日時、手配番号、配送便及び納品先というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図12(a)をわかりやすくするためにテーブル形式にすると図12(b)に示すようになる。すなわち、日時の列と、手配番号の列と、配送便の列と、納品先の列とを含むテーブルとなる。
また、品番DBのデータをCSV形式で取得した場合には、図13(a)に示すようなデータが分析対象データ格納部1に格納される。図13(a)の例では、品番及び品名というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図13(a)をわかりやすくするためにテーブル形式にすると図13(b)に示すようになる。すなわち、品番の列と、品名の列とを含むテーブルとなる。
業務システム分析装置の例えばイベント候補データ生成部3は、全ての解析対象テーブルについて処理したか判断する(ステップS3)。未処理の解析対象テーブルが存在する場合には、未処理の解析対象テーブルを1つ特定する(ステップS5)。そして、タイムスタンプ判定処理を実施する(ステップS7)。このタイムスタンプ判定処理については図14及び図15を用いて説明する。
まず、イベント候補データ生成部3のタイムスタンプ処理部31は、分析対象データ格納部1から、解析対象テーブルにおいて未処理のフィールドを1つ特定する(図14:ステップS31)。そして、分析対象データ格納部1において解析対象テーブルのスキーマ情報が使用可能となっているか判断する(ステップS33)。
スキーマ情報が使用可能となっている場合には、スキーマ情報において処理対象フィールドについてのデータ部分を特定し、その中で処理対象フィールドのデータ型がタイムスタンプ型であるか否か判断する(ステップS35)。処理対象フィールドのデータ型がタイムスタンプ型ではない場合にはステップS39に移行する。例えば、図9(a)乃至図13(a)のようなデータを処理する場合にはスキーマ情報はないので、ステップS39に移行する。
一方、処理対象フィールドのデータ型がタイムスタンプ型であると判断された場合には、処理対象フィールドのタイムスタンプ判定を「確定」と設定し、例えばメインメモリなどの記憶装置に格納する(ステップS37)。そして、処理はステップS43に移行する。
例えば、図4(a)のようなスキーマ情報の場合、フィールド1のデータ型がタイムスタンプ型であるので、フィールド1が処理対象フィールドであれば、タイムスタンプ判定=「確定」と設定される。図5(a)のようなスキーマ情報の場合、フィールド1のデータ型がタイムスタンプ型であるので、フィールド1が処理対象フィールドであれば、タイムスタンプ判定=「確定」と設定される。図6(a)及び図7(a)についても同様である。図8(a)の場合には、全フィールドについて、ステップS35からステップS39に移行する。
ステップS33でスキーマ情報が使用不能と判断された場合又は処理対象フィールドのデータ型がタイムスタンプ型でない場合、スコア表格納部35に格納されているタイムスタンプ確度スコア表を参照して、スキーマ情報における処理対象フィールドの該当データ部分、処理対象フィールドのフィールド名を表すラベルデータ、及び処理対象フィールドのフィールド値から確度を特定する(ステップS39)。
タイムスタンプ確度スコア表の一例を図15に示す。図15の例では、「フィールドのデータ型が可変長文字列」であれば確度スコアは1(%)と設定され、「フィールドのデータ型が実数」であれば確度スコアは5(%)と設定され、フィールド名の末尾が「時刻」「時間」などであれば確度スコアは90(%)と設定され、フィールド名の末尾が「月日」「日」などであって時刻などが含まれない場合であれば確度スコアは70(%)と設定され、フィールド名に「予定」「納期」など将来の時期を指定する場合であれば確度スコアは10(%)と設定され、フィールド値の文字列に年号(記号)、「/」「:」「’」「.」「−」、数字、空白といった時間に関連する文字以外の文字が含まれている場合には確度スコアは5(%)と設定され、フィールド値の文字列が「YYYY/MM/DD hh:mm:ss」の形式であれば確度スコアは90(%)と設定され、フィールド値の文字列が「YYYY/MM/DD」の形式であれば確度スコアは70(%)と設定され、フィールド値に同一となるものが含まれていれば確度スコアは30(%)と設定され、該当する項目がなければ確度スコアは50(%)と設定される。
例えば、図4(a)のようなスキーマ情報で図4(b)のようなレコード群の場合、フィールド2については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア5(%)と特定される。フィールド3についても同様に、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア5(%)と特定される。さらに、フィールド4については、データ型が可変長文字列であるので、確度スコア1(%)と特定される。なお、フィールド4については、フィールド値に時間に関連する文字以外の文字も含まれているので、タイムスタンプ確度スコア表において複数項目に該当しているが、本実施の形態では、50(%)という中央値からより乖離した値の方を採用する。すなわち、フィールド値に時間に関連する文字以外の文字が含まれている場合の確度スコア5(%)よりも1(%)を採用する。
一方、スキーマ情報が存在しない図9(a)の場合には、フィールド1については、フィールド値の文字列が「YYYY/MM/DD hh:mm:ss」の形式であるので、確度スコア90(%)と特定される。フィールド2及び3については同様であるが、フィールド4については、当該フィールドのデータ型が特定できないので、フィールド値に時間に関連する文字以外の文字が含まれている場合に該当すると判断され、確度スコア5(%)と特定される。
また、図5(a)のようなスキーマ情報で図5(b)のようなレコード群の場合にも、フィールド2乃至4については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア5(%)と特定される。フィールド5については、フィールド名の文字列に「納期」が含まれているので、確度スコア10(%)と特定される。なお、フィールド5については、フィールド値の文字列が「YYYY/MM/DD」の形式であるので、タイムスタンプ確度スコア表において複数項目に該当しているが、本実施の形態では、50(%)という中央値からより乖離した値の方を採用する。すなわち、フィールド値の文字列が「YYYY/MM/DD」の形式である場合の確度スコア70(%)よりも10(%)を採用する。スキーマ情報が存在しない図10(a)の場合には、フィールド1については、フィールド値の文字列が「YYYY/MM/DD hh:mm:ss」の形式であるので、確度スコア90(%)と特定される。フィールド2乃至5については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
さらに、図6(a)のようなスキーマ情報で図6(b)のようなレコード群の場合、フィールド2乃至5については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア5(%)と特定される。スキーマ情報が存在しない図11(a)の場合には、フィールド1については、フィールド値の文字列が「YYYY/MM/DD hh:mm:ss」の形式であるので、確度スコア90(%)と特定される。フィールド2乃至5については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
また、図7(a)のようなスキーマ情報で図7(b)のようなレコード群の場合、フィールド2乃至4については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア5(%)と特定される。スキーマ情報が存在しない図12(a)の場合は、フィールド1については、フィールド値の文字列が「YYYY/MM/DD hh:mm:ss」の形式であるので、確度スコア90(%)と特定される。フィールド2乃至4については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
さらに、図8(a)のようなスキーマ情報で図8(b)のようなレコード群の場合、フィールド1及び2については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア5(%)と特定される。スキーマ情報が存在しない図13(a)の場合も、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
図14の説明に戻って、処理対象フィールドのタイムスタンプ判定を特定された確度スコアに設定する(ステップS41)。上で述べた数値が特定される。
そして、処理対象テーブルにおいて全てのフィールドについて処理したか判断する(ステップS43)。未処理のフィールドが存在する場合にはステップS31に戻る。一方、全てのフィールドを処理した場合には元の処理に戻る。
このように、イベントのタイムスタンプとして蓋然性の高いフィールドに高い値の確度スコアが設定される。また、データ型からタイムスタンプであることが明らかであれば「確定」という蓋然性を表すデータが設定される。
図3の説明に戻って、次に、イベント候補データ生成部3のイベントID・関連ID候補処理部32は、イベントID及び関連ID候補判定処理を実施する(ステップS9)。このイベントID及び関連ID候補判定処理については、図16及び図17を用いて説明する。
イベントID・関連ID候補処理部32は、分析対象データ格納部1に格納されている解析対象テーブルのうち未処理のフィールドを1つ特定する(ステップS51)。そして、分析対象データ格納部1に格納されている、処理対象フィールドのフィールド値が、全レコードで一意となっているか判断する(ステップS53)。処理対象フィールドのフィールド値が、全レコードで一意となっていない、すなわち値が重複しているレコードが存在する場合には、ステップS62に移行する。
イベントIDはイベントの識別子の格納フィールドであるので、そのフィールド値が互いに重複することはない。したがって、処理対象フィールドに重複する値が存在すれば、それはイベントIDではないと判断できる。
一方、処理対象フィールドのフィールド値が、全レコードで一意である場合には、分析対象データ格納部1に格納されている、処理対象フィールドのフィールド値にNULLが含まれているか判断する(ステップS55)。処理対象フィールドのフィールド値にNULLが含まれている場合には、ステップS62に移行する。イベントIDはイベントの識別子の格納フィールドであるので、そのフィールド値がNULLということはあり得ないためである。処理対象フィールドのフィールド値が全レコードで一意とは言えない場合、又は処理対象フィールドのフィールド値にNULLを含む場合、分析対象データ格納部1に格納されている、処理対象フィールドのフィールド値が、NULLを除いて2以上あるか否か判断する(ステップS62)。処理対象フィールドのフィールド値が、NULLを除いて2種類以上ない場合には、イベントID・関連ID候補判定に「否定」を設定し、例えばメインメモリなどの記憶装置に格納する(ステップS63)。そして処理はステップS61に移行する。関連IDはあるイベントが他のイベントのどれに対応しているかを表す値であるので、そのフィールド値がNULLを除き2以上の値を有しない場合は、意味がある結果が得られないためである。
例えば図4(b)や図9(b)のようなテーブルの場合、フィールド1とフィールド2とフィールド4とについては、フィールド値に重複が存在せず、フィールド3ついてはフィールド値に重複が存在するが、NULL以外の2種類以上の値をとるので、イベントID・関連ID候補判定に「否定」は設定されない。
また図5(b)や図10(b)のようなテーブルの場合、フィールド1とフィールド2については、フィールド値に重複が存在せず、フィールド3乃至5については重複が存在するが、NULL以外の2種類以上の値をとるので、イベントID・関連ID候補判定に「否定」は設定されない。
さらに図6(b)や図11(b)のようなテーブルの場合、フィールド1とフィールド2については、フィールド値に重複が存在せず、フィールド3乃至5については重複が存在するが、NULL以外の2種類以上の値をとるので、イベントID・関連ID候補判定に「否定」は設定されない。
また図7(b)や図12(b)のようなテーブルの場合、フィールド1とフィールド2については、フィールド値に重複が存在せず、フィールド3及び4については重複が存在するが、NULL以外の2種類以上の値をとるので、イベントID・関連ID候補判定に「否定」は設定されない。
さらに図8(b)や図13(b)のようなテーブルの場合、フィールド1とフィールド2について、フィールド値に重複が存在しないので、イベントID・関連ID候補判定に「否定」は設定されない。
ステップS55において処理対象フィールドのフィールド値にNULLが含まれていないと判断された場合、又はステップS62において処理対象フィールドのフィールド値が、NULLを除いて2種類以上値を有すると判断された場合には、スコア表格納部35に格納されているイベントID・関連ID候補確度スコア表に従って、スキーマ情報における処理対象フィールドの該当データ部分、処理対象フィールドのフィールド名を表すラベルデータ、及び処理対象フィールドのフィールド値から確度を特定する(ステップS57)。但し、イベントID・関連ID候補確度スコア表に該当項目が存在しない場合には、確度スコア50(%)が特定されるものとする。
イベントID・関連ID候補確度スコア表の一例を図17に示す。図17の例では、フィールドのデータ型が可変長文字列であれば確度スコアは1(%)と設定され、フィールドのデータ型が実数であれば確度スコアは5(%)と設定され、フィールドのデータ型が整数であれば確度スコアは80(%)と設定され、フィールドのデータ型が固定長文字列であれば確度スコアは70(%)と設定され、フィールドのデータ型がタイムスタンプ又は日付であれば確度スコアは10(%)と設定され、フィールド名が主キー指定されていれば確度スコアは80(%)と設定される。フィールド値又はフィールド名の文字列についての項目はここでは定義されていないが、定義されることもある。フィールド値についての項目が定義される場合にはステップS57で参照される。
例えば図4(a)のようなスキーマ情報の場合、フィールド1についてはデータ型がタイムスタンプであるので確度スコア10(%)と特定され、フィールド2についてはデータ型が固定長文字列であって且つ主キー指定されているので50%からの乖離の大きい確度スコア80(%)が採用され、フィールド3についてはデータ型が固定長文字列であるので確度スコア70(%)と特定され、フィールド4についてはデータ型が可変長文字列であるので確度スコア1(%)と特定される。図9(a)のようなスキーマ情報が存在しない例の場合、フィールド1乃至フィールド4について、イベントID・関連ID候補確度スコア表には該当項目が存在しないので確度スコア50(%)が特定される。
例えば図5(a)のようなスキーマ情報の場合、フィールド1についてはデータ型がタイムスタンプであるので確度スコア10(%)と特定され、フィールド2についてはデータ型が固定長文字列であって且つ主キー指定されているので50%からの乖離の大きい確度スコア80(%)が採用され、フィールド3及びフィールド4についてはデータ型が固定長文字列であるので確度スコア70(%)が特定され、フィールド5についてはデータ型が日付となっているので確度スコア10(%)が特定される。図10(a)のようなスキーマ情報が存在しない例の場合、フィールド1乃至5について、イベントID・関連ID候補確度スコア表には該当項目が存在しないので確度スコア50(%)が特定される。
例えば図6(a)のようなスキーマ情報の場合、フィールド1についてはデータ型がタイムスタンプであるので確度スコア10(%)と特定され、フィールド2についてはデータ型が固定長文字列であって且つ主キー指定されているので50%からの乖離の大きい確度スコア80(%)が採用され、フィールド3乃至フィールド5についてはデータ型が固定長文字列であるので確度スコア70(%)が特定される。図11(a)のようなスキーマ情報が存在しない例の場合、フィールド1乃至5について、イベントID・関連ID候補確度スコア表には該当項目が存在しないので確度スコア50(%)が特定される。
例えば図7(a)のようなスキーマ情報の場合、フィールド1についてはデータ型がタイムスタンプであるので確度スコア10(%)と特定され、フィールド2についてはデータ型が固定長文字列であって且つ主キー指定されているので50%からの乖離の大きい確度スコア80(%)が採用され、フィールド3及びフィールド4についてはデータ型が固定長文字列であるので確度スコア70(%)が特定される。図12(a)のようなスキーマ情報が存在しない例の場合、フィールド1乃至4について、イベントID・関連ID候補確度スコア表には該当項目が存在しないので確度スコア50(%)が特定される。
例えば図8(a)のようなスキーマ情報の場合、フィールド1についてはデータ型が固定長文字列であって且つ主キー指定されているので50%からの乖離の大きい確度スコア80(%)が採用され、フィールド2についてはデータ型が固定長文字列であるので確度スコア70(%)が採用される。図13(a)のようなスキーマ情報が存在しない例の場合、フィールド1及び2について、イベントID・関連ID候補確度スコア表には該当項目が存在しないので確度スコア50(%)が特定される。
そして、イベントID・関連ID候補処理部32は、イベントID・関連ID候補判定に、ステップS57で特定された確度スコアを設定して、例えばメインメモリなどの記憶装置に格納する(ステップS59)。
その後、処理対象テーブルにおいて全てのフィールドについて処理したか判断し(ステップS61)、未処理のフィールドが存在する場合にはステップS51に戻る。一方、全てのフィールドについて処理した場合には元の処理に戻る。
このようにすれば、イベントID又は関連IDの蓋然性が高いものについては高い確度スコアが特定されるようになる。また、イベントID又は関連IDの可能性が完全にないものについては「否定」という蓋然性を表すデータが特定される。
図3の説明に戻って、次に、イベント候補データ生成部3のイベント名処理部34は、イベント名判定処理を実施する(ステップS13)。このイベント名判定処理については、図18乃至図20を用いて説明する。
まず、イベント名処理部34は、タイムスタンプ判定処理の処理結果として所定の確度スコア以上でタイムスタンプのフィールドとしてみなすことができるフィールドの数をカウントする(ステップS91)。例えば確度スコア70(%)以上などの閾値を設定する。当然ながら「確定」と特定されているフィールドはタイムスタンプのフィールドである。上で述べた例では、品番DBを除き、フィールド名が日時であるフィールドがタイムスタンプのフィールドと判断され、フィールド数は「1」となる。品番DBでは、タイムスタンプとみなすことができるフィールドはないので、フィールド数は「0」となる。
そして、タイムスタンプのフィールド数が0であるか否か判断する(ステップS93)。フィールド数が0であれば、解析対象テーブルを以下の処理の対象外として設定する(ステップS95)。タイムスタンプがないテーブル(例えば品番DB)は、業務プロセス中に発生するイベントに対応しているテーブルではないと判断される。そして元の処理に戻る。
一方、タイムスタンプのフィールド数が0ではない場合には、フィールド数が1であるか否か判断する(ステップS97)。タイムスタンプのフィールド数が1であれば、イベント名にテーブル名を設定し、例えばメインメモリなどの記憶装置に格納する(ステップS99)。上の例では、受注DBであれば、イベント名は「受注」と特定され、生産DBであれば、イベント名は「生産」と特定され、手配DBであれば、イベント名は「手配」と特定され、配送DBであれば、イベント名は「配送」と特定される。そして元の処理に戻る。
また、タイムスタンプのフィールド数が複数である場合には、タイムスタンプとみなされたフィールドのフィールド名をイベント名に設定し、例えばメインメモリなどの記憶装置に格納する(ステップS101)。そして元の処理に戻る。
例えば図19のようなテーブルが処理対象テーブルである場合にステップS101が実行される。図19の例では、起票日時、承認日時、発注日時、納品日時、検収日時がそれぞれイベントのタイムスタンプとみなされるフィールドとなり、1レコードにイベントが複数記録される形式となっている。このようなテーブルは、図20(a)乃至(e)に示したような起票テーブル、承認テーブル、発注テーブル、納品テーブル及び検収テーブルという複数テーブルとして扱うことができる。従って、このような場合には、「起票」「承認」「発注」「納品」「検収」がそれぞれイベント名として特定される。
以上のような処理を実施することによって、業務プロセス中に発生するイベントに対応しているテーブルを特定すると共に、イベント名を抽出することができるようになる。
図3の説明に戻って、次に、イベント候補データ生成部3は、判定結果を入出力部11を介してユーザに提示する(ステップS15)。例えば、図4(a)及び(b)に示したようなリレーショナルデータベース形式の受注DBの場合には、図21に示すようなデータがユーザに提示される。図21の例では、日時フィールド、受注番号フィールド、地域フィールド、受注内容フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、受注番号フィールド及び地域フィールドがイベントIDまたは関連IDの可能性が高いことが分かる。
また、図9(a)に示したCSV形式の受注DBの場合には、図22に示すようなデータがユーザに提示される。図22の例では、日時フィールド、受注番号フィールド、地域フィールド、受注内容フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントIDまたは関連IDである可能性はいずれのフィールドも同等であることが分かる。
例えば、図5(a)及び(b)に示したようなリレーショナルデータベース形式の生産DBの場合には、図23に示すようなデータがユーザに提示される。図23の例では、日時フィールド、生産番号フィールド、受注番号フィールド、品番フィールド、納期フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、生産番号フィールドと受注番号フィールドと品番フィールドがイベントIDまたは関連IDの可能性が高いことが分かる。
また、図10(a)に示したCSV形式の生産DBの場合には、図24に示すようなデータがユーザに提示される。図24の例では、日時フィールド、生産番号フィールド、受注番号フィールド、品番フィールド、納期フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントIDまたは関連IDである可能性はいずれのフィールドも同等であることが分かる。
例えば、図6(a)及び(b)に示したようなリレーショナルデータベース形式の手配DBの場合には、図25に示すようなデータがユーザに提示される。図25の例では、日時フィールド、手配番号フィールド、受注番号フィールド、品番フィールド、納品先フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、手配番号フィールドと受注番号フィールドと品番フィールドと納品先フィールドがイベントIDまたは関連IDの可能性が高いことが分かる。
また、図11(a)に示したCSV形式の手配DBの場合には、図26に示すようなデータがユーザに提示される。図26の例では、日時フィールド、手配番号フィールド、受注番号フィールド、品番フィールド、納品先フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントIDまたは関連IDである可能性はいずれのフィールドも同等であることが分かる。
例えば、図7(a)及び(b)に示したようなリレーショナルデータベース形式の配送DBの場合には、図27に示すようなデータがユーザに提示される。図27の例では、日時フィールド、手配番号フィールド、配送便フィールド、納品先フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、手配番号フィールドと配送便フィールドと納品先フィールドがイベントIDまたは関連IDの可能性が高いことが分かる。
また、図12(a)に示したCSV形式の配送DBの場合には、図28に示すようなデータがユーザに提示される。図28の例では、日時フィールド、手配番号フィールド、配送便フィールド、納品先フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントIDまたは関連IDである可能性はいずれのフィールドも同等であることが分かる。
例えば、図8(a)及び(b)に示したようなリレーショナルデータベース形式の品番DBの場合には、図29に示すようなデータがユーザに提示される。図29の例では、品番フィールド、品名フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、品番DBはタイムスタンプがないと判断され、以降の処理対象外とされているため、イベント名については全て「否定」とされている。これを見れば、タイムスタンプのフィールドが存在する可能性が非常に低く、品番フィールドと品名フィールドはイベントIDまたは関連IDの可能性が高いことが分かる。
また、図13(a)に示したCSV形式の品番DBの場合には、図30に示すようなデータがユーザに提示される。図30の例では、品番フィールド、品名フィールドのそれぞれにつき、ステップS7乃至S13の判定結果が提示されている。なお、品番DBはタイムスタンプがないと判断され、以降の処理対象外とされているため、イベント名については全て「否定」とされている。これを見れば、タイムスタンプのフィールドが存在する可能性は非常に低く、イベントIDまたは関連IDである可能性はいずれのフィールドも同等であることが分かる。
図3の説明に戻って、ステップS15が終了すると、ユーザは、入出力部11を介して、イベント名、タイムスタンプ、イベントID・関連ID候補などについて修正入力又は確定入力を行い、レコードのコピーなどを行って又は命じて、イベント候補データを生成し、イベント候補データ生成部3にイベント候補データ格納部5へ格納させる(ステップS16)。この作業は主に又は一部ユーザによって実施されるので、図3では点線ブロックで描かれている。そして処理はステップS3に戻る。
例えば図21の判定結果に従って、図31に示すようにイベント名についてはテーブル名である「受注」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については受注番号フィールド及び地域フィールドを確定させる場合、例えば図32に示すようなデータが、イベント候補データ格納部5に格納される。図32に示す例では、イベント名「受注」が全てのレコードに付加され、日時フィールドのフィールド値の全レコード分がタイムスタンプのフィールドにコピーされ、受注番号フィールド及び地域フィールドがイベントID・関連ID候補として、フィールド名とフィールド値の全レコード分がコピーされる。
例えば図22の判定結果に従って、イベント名についてはテーブル名である「受注」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については受注番号フィールド、地域フィールド及び受注内容フィールドを確定させる場合、例えば図33のようなデータが、イベント候補データ格納部5に格納される。
さらに例えば図23の判定結果に従って、イベント名についてはテーブル名である「生産」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については生産番号フィールド、受注番号フィールド及び品番フィールドを確定させる場合、例えば図34のようなデータが、イベント候補データ格納部5に格納される。
また例えば図24の判定結果に従って、イベント名についてはテーブル名である「生産」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については生産番号フィールド、受注番号フィールド、品番フィールド及び納期フィールドを確定させる場合、例えば図35のようなデータが、イベント候補データ格納部5に格納される。
さらに例えば図25の判定結果に従って、イベント名についてはテーブル名である「手配」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については手配番号フィールド、受注番号フィールド、品番フィールド及び納品先フィールドを確定させる場合、例えば図36のようなデータが、イベント候補データ格納部5に格納される。
また例えば図26の判定結果に従って、イベント名についてはテーブル名である「手配」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については手配番号フィールド、受注番号フィールド、品番フィールド及び納品先フィールドを確定させる場合、例えば図37のようなデータが、イベント候補データ格納部5に格納される。
さらに例えば図27の判定結果に従って、イベント名についてはテーブル名である「配送」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については手配番号フィールド、配送便フィールド及び納品先フィールドを確定させる場合、例えば図38のようなデータが、イベント候補データ格納部5に格納される。
また例えば図28の判定結果に従って、イベント名についてはテーブル名である「配送」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントID・関連ID候補については手配番号フィールド、配送便フィールド及び納品先フィールドを確定させる場合、例えば図39のようなデータが、イベント候補データ格納部5に格納される。
また、例えば図19のようなテーブル内に複数のタイムスタンプのフィールドが存在するようなテーブルを処理対象とする場合は、例えば図40乃至図44に示すようなデータが、イベント候補データ格納部5に格納される。図40乃至図44に示す例では、タイムスタンプとして確定されたフィールドである起票日時、承認日時、発注日時、納品日時、検収日時を元に、それらのフィールド毎に、各々イベント名を「起票」、「承認」、「発注」、「納品」、「検収」と確定させたイベント候補データを作成する。タイムスタンプについては、起票日時フィールド、承認日時フィールド、発注日時フィールド、納品日時フィールド、検収日時フィールドのフィールド値の全レコード分が各々のイベント候補データのタイムスタンプのフィールドにコピーされる。さらに、全てのイベント候補データ共通に、起票日時フィールド、承認日時フィールド、発注日時フィールド、納品日時フィールド、検収日時フィールド以外のフィールドについては、イベントID・関連ID候補として、フィールド名とフィールド値の全レコード分がコピーされる。
このようにして以下の処理で用いるイベント候補データがイベント候補データ格納部5に格納されるようになる。
図3の説明に戻って、ステップS3で全ての解析対象テーブルを処理したと判断された場合には、イベントデータ生成部7は、イベント候補データ格納部5に格納されているイベント候補データを用いて、イベントデータ生成処理を実施し、処理結果をイベントデータ格納部9に格納する(ステップS17)。
受注イベント、生産イベント、手配イベント、配送イベントに対応して、各々、図32、図34、図36、図38に示されたイベント候補データのセット、または、各々、図33、図35、図37、図39に示されたイベント候補データのセットを用いて生成したイベントデータの例を図45に示す。その生成方法としては、上で述べた特開2008−27072号公報記載のようなイベントデータの関連情報の自動抽出方式を用いても良いし、人手によって、各イベント候補データのイベントID・関連ID候補のフィールド値の対応関係を調査・分析することによって、イベント間の関連性を確定しても良い。
図45では、受注イベントのイベントIDは受注番号であり、生産イベントのイベントIDは生産番号、関連IDは受注番号であり、手配イベントのイベントIDは手配番号、関連IDは受注番号であり、配送イベントのイベントIDは手配番号、関連IDは配送便であることが確定されている。また、生産イベントの関連IDのフィールド値が、受注イベントのイベントIDのフィールド値のどれかの値をとることにより、生産イベントの各々のレコード(すなわち、イベントインスタンス)が、受注イベントのどのレコード(すなわち、イベントインスタンス)と関連しているかが特定されるというイベント間の関連性が確定されている。同様の関連性が、手配イベントの関連IDと受注イベントのイベントIDとの間、配送イベントのイベントIDと手配イベントのイベントIDとの間に確定されている。
また、プロセスインスタンス生成部13は、イベントデータ格納部9に格納されているイベントデータを用いてプロセスインスタンス生成処理を実施し、処理結果をプロセスインスタンスデータ格納部15に格納する(ステップS19)。その生成方法としては、米国特許公開公報2005/076059A1のような業務プロセストラッキング方法等を用いることができる。
図45のイベントデータを用いて、受注番号:JT01の受注イベントインスタンスを起点とするプロセスインスタンスを生成する処理過程の概略説明を図46に示す。最初に、関連IDのフィールド値が、受注イベントのイベントIDである受注番号のフィールド値:JT01をとるレコード(すなわち、イベントインスタンス)として、生産イベントから2つ、手配イベントから3つのイベントインスタンスが確定される。次に、確定された手配イベントのイベントIDである手配番号:TH01,TH02,TH03を関連IDのフィールド値としてとるレコード(すなわち、イベントインスタンス)として、配送イベントから3つのイベントインスタンスが確定される。最後に、確定された、受注番号:JT01の受注イベントインスタンスを起点として、直接・間接的に関連性をもつイベントインスタンスを、そのタイムスタンプの値に基づいて時間経過の順につなぎ合わせることによって、プロセスインスタンスが生成される。すなわち、第1のプロセスインスタンスとしては、イベントクラスが、受注、生産、手配、手配、手配、配送、生産、配送、配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスが生成される。
同様にして、図45のイベントデータを用いて生成した全プロセスインスタンスを図47に示す。第2のプロセスインスタンスは、イベントクラスが、受注、手配及び配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスである。第3のプロセスインスタンスは、イベントクラスが、受注、生産、生産、手配及び配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスである。さらに、第4のプロセスインスタンスは、イベントクラスが、受注、手配及び配送であるイベントインスタンスが時系列に並べられたプロセスインスタンスである。
図3の処理フローの説明に戻って、次に、並列処理推定部17は、プロセスインスタンスデータ格納部15に格納されているプロセスインスタンスのデータを用いて、並列処理推定処理を実施する(ステップS21)。この処理については、図48乃至図74を用いて詳細に説明する。
まず、図48乃至図56−2を用いて並列処理推定処理を実施する趣旨について説明する。まず、図48に示すように、プロセスインスタンスデータ格納部15に10個のプロセスインスタンスが格納されているものとする。それらのプロセスインスタンスを構成する各々のイベントインスタンスが属するイベントクラスの並び方に基づいて、プロセスインスタンスを分類し、グループ化し、メンバのプロセスインスタンスの数が多い順に並べると次のようになる。このような処理はプロセスインスタンス分類処理部21で実施される。先ず、イベントクラスの並び方がInitial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateであるプロセスインスタンスが5つでグループAが構成される。また、Initial State、契約、伝票作成、請求及び回収の後に契約更新を介して伝票作成に戻って請求及び回収の後、さらに契約満了及びFinal Stateが発生するプロセスインスタンスが3つでグループBが構成される。さらに、Initial State、契約、伝票作成、請求及び回収の後に継続を介して請求に戻って、回収、契約満了及びFinal Stateが発生するプロセスインスタンスが1つでグループCが構成される。そして、Initial State、契約、伝票作成、請求の後、回収、回収と繰り返した後、契約満了及びFinal Stateが発生するプロセスインスタンスが1つでグループDが構成される。ただし、Initial State及びFinal Stateは、各プロセスインスタンスの先頭・末尾に付けられる仮想的なイベントクラスである。
このようなグループA乃至Dのプロセスインスタンスのグループをプロセス表示処理部25により重ね合わせ表示すると、図49に示すような全体フローが表示される。この表示では、各イベントクラスを示す楕円を各1個のみ表示し、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため1本のみとしている。
また、例えばグループの出現頻度の全体に対して占める比率20%を閾値として、主要フローと例外フローとに分ける場合には、図50(a)に示すように、主要フローとしては、グループAとグループBのプロセスインスタンスが重ね合わされたフローが生成され、ユーザに提示される。この表示では、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため1本のみとしている。これに対して、例外フローは、図50(b)に示すグループCのプロセスインスタンス、図50(c)に示すグループDのプロセスインスタンスがユーザに提示される。
図48に示したプロセスインスタンスの場合には、主要フローと例外フローに分ける上で問題はあまりなく、ユーザは、図49や図50に示したような図で、業務フローの概況を容易に把握できるようになる。グループAだけでも50%の出現頻度を占めるため、グループAのみを主要フローとして認めても、図50と同様に、業務フローの概況を把握する上で特別に問題はない。
一方、図56に示すように、実際の業務に並列処理の部分が存在する業務フロー(図54)を持つシステムから得られたデータに対して、ステップS1乃至S19までの処理を行うと、図51に示すように、実際の業務には存在しない見かけ上遷移を構成要素として含むプロセスインスタンスが生成される。その理由は、互いのIDに関連性が有るイベント同士を単純に時系列に繋ぐため、図54の並列処理を含む業務フローでは、互いに並列関係にある部分フロー中のイベント間に見かけ上の遷移を誤設定するためである。
図54に示す並列処理を含む業務フローは、Initial State、契約というイベントクラスが並んでいる部分フローの後に、伝票作成、請求、回収というイベントクラスが並んでいる部分フローと、継続及び契約更新というイベントクラスが並んでいる部分フローとが、互いに並列の関係で続き、その後に、契約満了、Final Stateというイベントクラスが並んでいる部分フローに合流している。分析対象の業務システム・業務フローに、このような互いに並列関係にある部分フローを含むことが既知である場合には、それらの並列関係を反映したデータの前処理、例えば、互いに並列関係にある部分フローのうち1つのみを残して他の部分フローを構成するイベントクラスのデータを削除する処理などを行う必要がある。
しかし、分析対象の業務システム・業務フロー中の並列処理の存在や、どのような並列処理が存在するかについての十分な情報がなく、データの前処理を行えずに、ステップS1乃至S19までの処理を行わざるを得ない場合がある。その場合には、図51に示すようなプロセスインスタンスが生成される。具体的には、Initial State、契約、伝票作成、請求、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいる基本的なプロセスインスタンスが4つ存在しており、グループFを構成している。一方、上で述べたように、互いに並列関係にある、伝票作成、請求、回収というイベントクラスが並んでいる部分フローと、継続及び契約更新というイベントクラスが並んでいる部分フローの構成要素のイベントインスタンス同士間に、実際の業務フローとは関係ない見かけ上遷移を設定してしまった、A乃至Eのような1つのプロセスインスタンスで構成されるグループが得られてしまう。グループAには、Initial State、契約、「伝票作成、継続、請求、契約更新、回収」、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。グループBには、Initial State、契約、伝票作成、「請求、継続、回収、契約更新」、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。さらに、グループCには、Initial State、契約、伝票作成、請求、「回収、継続」、契約更新、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。また、グループDには、Initial State、契約、継続、「契約更新、伝票作成」、請求、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。さらに、グループEには、Initial State、契約、「継続、伝票作成、契約更新、請求」、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを含む。このように「」で示したイベントインスタンス間の遷移が見かけ上遷移である。図73に、それらの見かけ上遷移を点線で表示して示す。なお、図51には、グループA乃至Eとは別に、Initial State、契約、伝票作成、請求、請求、回収、契約満了、Final Stateというイベントクラスに属するイベントインスタンスが並んでいるプロセスインスタンスを1つ含むグループGも存在する。グループGでは、請求というイベントクラスに属するイベントインスタンスが繰り返されている。
このような全プロセスインスタンスを単純に重ね合わせると図52に示すような業務フローが得られる。図52を見れば分かるように、業務フロー全体を把握するには煩雑すぎる。また、上で述べたのと同様に閾値20%で主要フローと例外フローとを分けると、図53に示すようになる。すなわち、グループFは全体の40%で主要フローと判断されるが、グループA乃至E及びGについては全て10%であるから例外フローと判断される。しかしながら、実はグループA乃至Eは、図54に示すような並列処理を含む業務フローから生成されたイベントインスタンスを、単純に日時の順番に連結してしまったために見かけ上遷移を構成要素とするプロセスインスタンスとして生成されたものである。すなわち、本来、生成されるべきプロセスインスタンスは、契約、伝票作成、請求、回収、契約満了という順番でイベントインスタンスが発生する主要経路と、契約から分岐して継続及び契約更新と続き契約満了に遷移する並列経路とを含むプロセスインスタンスである。
グループA乃至Eを、図54−2に示すような本来の並列経路を含むプロセスインスタンスに修正すると、図55に示すように、これら(グループAE)は全体の50%を占めるようになるため、これらが第1の主要フローとなり、グループFは第2の主要フローとなる。従って、例外フローはグループGのみとなる。全プロセスインスタンスを重ね合わせたとしても、図56−2に示すように、図52と比べて格段に整理され、把握のしやすい業務フローをユーザに提示できるようになる。
そこで、図57乃至図74に示すような処理を実施することによって、従来技術で生成したプロセスインスタンスにおいて見かけ上の遷移であって実際の業務上は遷移が発生している可能性が低いものを検出し、業務フローにおける並列処理の存在を推定することによって、ユーザが本来の業務フローの概要を把握できるようにする。
並列処理推定部17の統計情報抽出部171は、プロセスインスタンスデータ格納部15に格納されているプロセスインスタンスからイベント間遷移頻度表を生成し、統計情報格納部173に格納する(図57:ステップS111)。発側イベントクラスと着側イベントクラスとの各組み合わせについて、プロセスインスタンスデータ格納部15に格納されているプロセスインスタンスにおける、該当発側イベントインスタンスと該当着側イベントインスタンスの組み合わせについてのイベント間遷移の発生頻度をカウントして、イベント間遷移頻度表に登録する。図58に模式的に示すように、例えば発側イベントクラスとして「請求」と着側イベントクラスとして「回収」との組み合わせに着目すると、点線で囲まれた部分がカウントされる。すなわち、プロセスインスタンスC、D、E及びGで1回、プロセスインスタンスFで4回カウントされるので、合計8回となる。よって図58の下段テーブルに示すように、発側イベントクラス「請求」と着側イベントクラス「回収」の対応セルに「8」が登録される。このような処理を全てのイベントクラスの組み合わせについて実施すれば、図59に示すようなイベント間遷移頻度表が生成される。図59の例では、横方向に着側イベントクラスが列挙され、縦方向に発側イベントクラスが列挙されている。ただし、Initial State及びFinal Stateは、各プロセスインスタンスの先頭・末尾に付けられる仮想的なイベントクラスであり、Initial Stateに到着するイベント間遷移及び、Final Stateから出発するイベント間遷移は存在しないので、それらに対応するセルには「−」が記載されている。
次に、統計情報抽出部171は、統計情報格納部173に格納されているイベント間遷移頻度表から、各イベントの発生確率及び条件付き確率の近似値を算出し、統計情報格納部173に格納する(ステップS113)。本ステップでは、図60に示すように、各発側イベントXを固定し、着側イベント全てとの組み合わせについてイベント間遷移頻度F(Y|X)の総和をとることで、各イベントクラスXに属するイベントインスタンスの発生頻度T(X)を計算する。以下、記述の煩雑を避けるため、各イベントクラスXに属するイベントインスタンスの発生頻度を、各イベントXの発生頻度と略する。なお、本実施の形態で取り扱う各プロセスインスタンスの先頭・末尾に付けられる仮想的なイベントクラスであるInitial State 及びFinal Stateを有するような状態遷移頻度表の場合には、着側のイベントYを固定し、発側イベント全てとの組み合わせについて頻度F(Y|X)の総和をとることによって、各イベントYの発生頻度T(Y)を算出しても同じ値が得られる。次に、イベント全部の発生頻度の和GTを算出する。さらに、全てのプロセスインスタンスに含まれ、イベントクラスXに属するイベントインスタンスの数を直接カウントすることで、各イベントXの発生頻度T(X)を求めるようにしても良い。次に、全イベントクラスについて、T(X)の和を計算することで、総イベント発生頻度GTを算出する。なお、総イベント発生数GTは、全てのプロセスインスタンスに含まれ、仮想的なイベントクラスであるInitial State 及びFinal State以外のイベントクラスに属するイベントインスタンスの数を直接カウントすることで、求めるようにしても良い。
そして、図61に示すように、各イベントクラスXに属するイベントインスタンスの発生確率の近似値をP(X)≒T(X)/GTとして算出して、統計情報格納部173に格納する。以下、記述の煩雑をさけるため、各イベントクラスXに属するイベントインスタンスの発生確率を、各イベントXの発生確率と略する。同様にして、図62に示すように、発側イベントXが発生した場合に着側イベントYが発生する条件付き確率P(Y|X)の近似値を、P(Y|X)≒F(Y|X)/T(X)として算出して、統計情報格納部173に格納する。以下、記述の煩雑をさけるため、発側イベントXが発生した場合に着側イベントYが発生する条件付き確率を、曖昧とならない場合は適宜、条件付き確率と略する。
図59の例を基にイベントの発生確率P(X)の近似値を算出すると、図63に示すようなデータが統計情報格納部173に格納される。また、同じく図59の例を基に条件付き確率P(Y|X)の近似値を算出すると、図64に示すようなデータが統計情報格納部173に格納される。
次に、統計情報抽出部171は、統計情報格納部173に格納されている各イベントの発生確率及び条件付き確率に基づき、各遷移について見かけ上遷移の評価指標値を算出し、統計情報格納部173に格納する(ステップS115)。上でも述べたが、見かけ上遷移とは、業務システムから得られたデータに対して、ステップS1乃至S19までの処理を機械的に適用し、イベントIDを共有または、関連IDを介して対応関係のあるイベントインスタンス(のレコード)を、単純に発生日時に基づき直列的に接続することで作成したプロセスインスタンスを構成する遷移だが、実際の業務上は存在しない遷移である。
見かけ上遷移検出評価指標値は、以下の統計的な性質を用いて定義される。先ず、事象Aが発生する場合に事象Bが発生する条件付き確率P(B|A)は、事象Aが発生し、かつ、事象Bが発生する確率P(A∩B)に対して、等式P(A∩B)=P(B|A)P(A)を成り立たせるものとして定義される。一方、図65に示すように、事象Aと事象Bとが独立に発生する場合には、事象Aと事象Bとに重複する部分は存在しない。すなわち、事象Aと事象Bとが独立事象である必要十分条件は、AとBとが同時に発生する確率P(A∩B)は、事象Aが発生する確率P(A)と事象Bが発生する確率P(B)について、P(A∩B)=P(A)P(B)が成り立つことである。したがって、事象Aと事象Bとが独立に発生する場合には、事象Aが発生する場合に事象Bが発生する条件付き確率P(B|A)については、P(B|A)=P(B)が導出される。同様に、事象Bが発生する場合に事象Aが発生する条件付き確率P(A|B)についても、P(A|B)=P(A)が導出される。
プロセスインスタンスに主要経路と分岐した並列経路とが含まれている場合、すなわち、並列処理を含む業務フローから発生したプロセスインスタンスの場合、主要経路中のイベントクラスのイベントインスタンスと、並列経路中のイベントクラスのイベントインスタンスとは、互いに業務上無関係であるので、独立に発生するとみなすことができる。従って、見かけ上遷移の条件付き確率P(見かけ上遷移の着側イベント|見かけ上遷移の発側イベント)と、見かけ上遷移の着側イベントのイベントクラスに属するイベントインスタンスの発生確率P(見かけ上遷移の着側イベント)について、P(見かけ上遷移の着側イベント|見かけ上遷移の発側イベント)=P(見かけ上遷移の着側イベント)が成立する。
すなわち、|1−P(見かけ上遷移の着側イベント|見かけ上遷移の発側イベント)/P(見かけ上遷移の着側イベント)|=0が導出される。従って、本実施の形態における見かけ上遷移の評価指標式としては、|1−P(判断対象遷移の着側イベント|判断対象遷移の発側イベント)/P(判断対象遷移の着側イベント)|を採用する。さらに、閾値としては、例えば「1」を採用する。但し、実験的に最適値を求めてその値を用いるようにしても良い。さらに、同様の趣旨に従って定義される他の評価式を採用するようにしても良い。
図63及び図64から見かけ上遷移評価指標値を算出すると、図66に示すような値が得られる。発側イベントと着側イベントが同一の場合には、手戻りを示しており、並列処理とは関係ないので、「−」で示すように評価指標値を算出しない。そうすると、ハッチングが付されているセルに対応する遷移が、評価指標値が「1」未満となる。すなわち、伝票作成から契約更新への遷移、伝票作成から継続への遷移、請求から契約更新への遷移、請求から継続への遷移、回収から契約更新への遷移、回収から継続への遷移、契約更新から伝票作成への遷移、契約更新から請求への遷移、契約更新から回収への遷移、継続から伝票作成への遷移、継続から請求への遷移及び継続から回収への遷移が、評価指標値が閾値未満となっている。
図57の処理の説明に戻って、見かけ上遷移検出部175は、統計情報格納部173に格納されている評価指標値が閾値以下である遷移を見かけ上遷移(具体的には、発イベントクラス及び着イベントクラスの組)として検出し、見かけ上遷移削除部177及び代替遷移決定処理部179に出力する(ステップS117)。端子Aを介して図67の処理に移行する。
図67の処理の説明に移行して、見かけ上遷移削除部177は、プロセスインスタンスデータ格納部15において未処理のプロセスインスタンスを1つ特定する(ステップS119)。そして、見かけ上遷移削除部177は、見かけ上遷移検出部175から受け取った見かけ上遷移のうち未処理の遷移を1つ特定する(ステップS121)。そして、見かけ上遷移削除部177は、特定されたプロセスインスタンスが、特定された見かけ上遷移を含むか確認する(ステップS123)。図66のような評価指標値が計算された場合には、ハッチングが付された12種類の遷移が見かけ上遷移として検出されるので、見かけ上遷移のうちいずれか1つでも含むプロセスインスタンスを抽出する。特定されたプロセスインスタンスが、特定された見かけ上遷移を含まない場合には、見かけ上遷移削除部177は、全ての見かけ上遷移について処理したか判断する(ステップS125)。ここで未処理の見かけ上遷移が存在する場合にはステップS121に戻る。
一方、全ての見かけ上遷移について処理したが、特定されたプロセスインスタンスに見かけ上遷移が検出されなかった場合には、見かけ上遷移削除部177は、特定されたプロセスインスタンスのデータを、並列処理推定後プロセスインスタンスデータ格納部19に格納する(ステップS127)。そしてステップS135に移行する。見かけ上遷移を含んでいない、すなわち、並列処理を含んでいないと判断されたプロセスインスタンスについては、ステップS23以降の処理のために並列処理推定後プロセスインスタンス格納部19に格納する。
これに対して、特定されたプロセスインスタンスに、特定された見かけ上遷移が含まれている場合には、見かけ上遷移削除部177は、特定されたプロセスインスタンスのデータを、並列処理該当プロセスインスタンスデータ格納部181に格納する(ステップS129)。そして、見かけ上遷移削除部177は、特定されたプロセスインスタンスにおいて、特定された見かけ上遷移を削除する(ステップS131)。例えば、図51のプロセスインスタンスAをステップS119で特定した場合には、プロセスインスタンスAにおいて、見かけ上遷移として検出された遷移に該当する遷移(伝票作成から継続への遷移、継続から請求への遷移、請求から契約更新への遷移、契約更新から回収への遷移)のうちいずれかがステップS131で削除される。図68では、既に全ての見かけ上遷移が削除されているが、例えば、伝票作成に対応するデータブロックから継続に対応するデータブロックへの接続を表すポインタが削除される。
さらに、見かけ上遷移削除部177は、特定されたプロセスインスタンスに、残余の見かけ上遷移が含まれるか否かを判断し、含まれている場合には該当する遷移を削除する(ステップS133)。例えば、ステップS121でまだ特定されていない未処理の見かけ上遷移の各々について、特定されたプロセスインスタンスに含まれるか否かを判断し、含まれていれば、該当する全ての遷移を削除する。プロセスインスタンスAの場合には、図68に示すように、×印が付されている遷移のためのポインタが削除される。その後ステップS135に移行する。
ステップS135では、見かけ上遷移削除部177は、プロセスインスタンスデータ格納部15における全てのプロセスインスタンスについて処理したか判断する。未処理のプロセスインスタンスが存在する場合にはステップS119に戻る。一方、全てのプロセスインスタンスを処理した場合には、端子Bを介して図69の処理に移行する。
図69の処理の説明に移行して、代替遷移決定処理部179は、並列処理該当プロセスインスタンスデータ格納部181において未処理の抽出プロセスインスタンスを1つ特定する(ステップS137)。そして、代替遷移決定処理部179は、特定された抽出プロセスインスタンスにおいて少なくとも一端が未接続のイベントインスタンスのうち未処理のイベントインスタンスを1つ特定する(ステップS139)。図68の例で、例えば継続が特定されるものとする。
そして、代替遷移決定処理部179は、特定されたイベントインスタンスの前方(時間的に前)が未接続であるか判断する(ステップS141)。特定されたイベントインスタンスの前方は接続されている場合にはステップS157に移行する。一方、特定されたイベントインスタンスの前方が未接続の場合、代替遷移決定処理部179は、接続先を探すためのポインタnを2に初期化する(ステップS145)。n=1は図67の処理で削除されている遷移なのでn=2からスタートする。そして、代替遷移決定処理部179は、n個前のイベントが存在するか判断する(ステップS147)。n個前のイベントが存在しない場合、特定されたイベントインスタンスについて前方に接続できるイベントインスタンスが存在しないということなので、代替遷移決定処理部179は、「Initial State」から本イベントインスタンスへの遷移を設定する(ステップS155)。「Initial State」については仮想的なイベントなので、図68に示すように、それ自体のデータを保持しない場合もある。保持する場合には、「Initial State」のデータブロックにおいて遷移先を表すポインタに、本イベントインスタンスについてのデータブロックのアドレスを追加する。一方、図68に示すように保持していない場合には、本イベントインスタンスについてのデータブロックに、遷移元を表すデータとして「Initial State」を表すデータを追加する。処理はステップS157に移行する。
一方、n個前のイベントインスタンスが存在する場合には、代替遷移決定処理部179は、n個前のイベントインスタンスから、特定されたイベントインスタンスへの遷移が、見かけ上遷移に該当するか確認する(ステップS149)。プロセスインスタンスAであれば、特定されたイベントインスタンスが「継続」であれば、2個前のイベントインスタンスは「契約」というイベントクラスのイベントインスタンスであるから、見かけ上遷移に該当しない。n個前のイベントインスタンスから処理に係るイベントインスタンスへの遷移が見かけ上遷移に該当しない場合には、代替遷移決定処理部179は、n個前のイベントインスタンスから処理に係るイベントインスタンスへの遷移を設定する(ステップS153)。図68の「継続」の場合には、図70に模式的に示すように「契約」についてのデータブロックに「継続」についてのデータブロックへのポインタを追加する。処理はステップS157に移行する。
一方、図71に示すように、プロセスインスタンスBの「継続」というイベントクラスのイベントインスタンスについて処理する場合、2つ前のイベントインスタンスは「伝票作成」というイベントクラスのイベントインスタンスであって、「伝票作成」から「継続」への遷移が見かけ上遷移に該当するため選択できない。
すなわち、n個前のイベントインスタンスから処理に係るイベントインスタンスへの遷移が見かけ上遷移に該当する場合には、代替遷移決定処理部179は、nを1インクリメントして(ステップS151)、ステップS147に戻る。
図71の例では、3つ前のイベントインスタンスは「契約」というイベントクラスのイベントインスタンスであって、「契約」から「継続」への遷移が見かけ上遷移に該当しないので、「契約」についてのデータブロックに「継続」についてのデータブロックへのポインタを追加する。
ステップS157では、代替遷移決定処理部179は、特定されたイベントインスタンスの後方(時間的に後ろ)が未接続であるか判断する。既に遷移が確定している場合には端子Cを介して図72のステップS171に移行する。一方、特定されたイベントインスタンスの後方が未接続である場合には端子Dを介して図72のステップS159に移行する。
図72の処理の説明に移行して、代替遷移決定処理部179は、nを2に初期化し(ステップS159)、特定された抽出プロセスインスタンスにおいて、n個後のイベントインスタンスが存在するか判断する(ステップS161)。n個後のイベントが存在しない場合、特定されたイベントインスタンスについて後方に接続できるイベントインスタンスが存在しないということなので、代替遷移決定処理部179は、本イベントインスタンスから「Final State」への遷移を設定する(ステップS163)。「Final State」については仮想的なイベントなので、図68に示すように、それ自体のデータを保持しない場合もある。保持する場合には、本イベントインスタンスについてのデータブロックに、「Final State」についてのデータブロックのアドレスを遷移先を表すポインタとして追加する。一方、図68に示すように保持していない場合には、本イベントインスタンスについてのデータブロックに、遷移先を表すデータとして「Final State」を表すデータを追加する。処理はステップS171に移行する。
一方、n個後のイベントインスタンスが存在する場合には、代替遷移決定処理部179は、特定されたイベントインスタンスからn個後のイベントインスタンスへの遷移が、見かけ上遷移に該当するか確認する(ステップS165)。プロセスインスタンスA及びBにおいて、特定されたイベントインスタンスが「継続」であれば、2個後のイベントインスタンスは「契約更新」というイベントクラスのイベントインスタンスであるから、見かけ上遷移に該当しない。特定されたプロセスインスタンスからn個後のイベントインスタンスへの遷移が見かけ上遷移に該当しない場合には、代替遷移決定処理部179は、特定されたプロセスインスタンスからn個後のイベントインスタンスへの遷移を設定する(ステップS169)。図70及び図71の「継続」の場合には、「継続」についてのデータブロックに「契約更新」についてのデータブロックへのポインタを追加する。処理はステップS171に移行する。
一方、特定されたイベントインスタンスからn個後のイベントインスタンスへの遷移が見かけ上遷移に該当する場合には、代替遷移決定処理部179は、nを1インクリメントして(ステップS167)、ステップS161に戻る。
ステップS171では、代替遷移決定処理部179は、少なくとも一端が未接続となっている全てのイベントインスタンスについて処理したか判断する。未処理のイベントインスタンスが存在する場合には、端子Eを介して図69のステップS139に戻る。一方、少なくとも一端が未接続となっている全てのイベントインスタンスについて処理した場合には、並列処理該当プロセスインスタンスデータ格納部181に格納されている全ての抽出プロセスインスタンスについて処理したか判断する(ステップS173)。未処理の抽出プロセスインスタンスが存在する場合には端子Fを介して図69のステップS137に戻る。全ての抽出プロセスインスタンスについて処理した場合には、代替遷移決定処理部179は、並列処理該当プロセスインスタンスデータ格納部181に格納されているプロセスインスタンスのデータを、並列処理推定後プロセスインスタンスデータ格納部19に移動させる(ステップS175)。
このような処理を行うと、プロセスインスタンスA乃至Eにおいては、図73において点線で示すように、本来の遷移ではなく見かけ上遷移に該当すると統計的に判断された遷移については切断され、その切断された遷移の両端のイベントインスタンスについて、切断された側で最も時間的に近くに発生し、かつ、当該イベントインスタンスとの間の遷移が、見かけ上遷移に該当しない遷移であるイベントインスタンスを探し、当該イベントインスタンスと探しだしたイベントインスタンス間の遷移を新たな遷移として設定すると、図74に示すようなプロセスインスタンスA乃至Eが得られるようになる。
なお、新たに生成した遷移については、イベントインスタンスの列とはずれた形で矢印で示しているのでわかりにくいが、結局のところ、プロセスインスタンスA乃至Eは、図54に示した業務上の並列処理を含む業務フローと同じ形になっている。
上の説明では、見かけ上遷移の削除及び代替遷移の設定について自動的に実施するような例を示したが、例えば、入出力部11に対して、該当するプロセスインスタンスと見かけ上遷移を提示し、ユーザに、当該見かけ上遷移を削除しても良いか確認するようにしても良い。この場合、削除が指示されればそれに応じて削除する。さらに、代替遷移の設定についても、ユーザに確認の上設定するようにしても良い。すなわち、代替遷移を上で述べた処理にて特定して提示するようにしても良いし、全く提示せずにユーザにより入力してもらうようにしても良い。
図3の説明に戻って、プロセスインスタンス分類処理部21は、並列処理推定後プロセスインスタンスデータ格納部19に格納されているプロセスインスタンスを分類し、分類結果に基づき種類毎に計数して、種類毎に計数値をモデルデータ格納部23に格納する(ステップS23)。図55に示されたようなプロセスインスタンスが生成された場合には、ステップS23を実施すると図75に示すようなデータが、モデルデータ格納部23に格納される。図75の例では、上で述べた3つのグループのプロセスインスタンスと、それぞれの計数値が登録されている。なお、主要フローフラグの欄には、この段階では何も登録されない。
そして、プロセス表示処理部25は、モデルデータ格納部23に格納されているデータを用いて、フロー表示処理を実施する(ステップS25)。フロー表示処理について図76及び図77を用いて説明する。
まず、プロセス表示処理部25は、モデルデータ格納部23に格納されているプロセスインスタンスのグループを計数値に基づき降順に整列させる(ステップS141)。そして、各プロセスのグループを主要フローとして扱うための判断基準となる、当該グループのプロセスインスタンスの全体に占める比率の閾値を、ユーザから入力された場合には当該入力値により、ユーザの入力がない場合には予め設定されている値で決定する(ステップS143)。例えば全体に占める比率の閾値20%以上のグループを主要フローと分類する場合には、20%を入力する。但し、予め設定されている値(例えば30%)をそのまま用いるようにしても良い。
そして、プロセス表示処理部25は、計数値上位より1つ未選択のプロセスインスタンスを選択する(ステップS147)。この選択されたプロセスインスタンスを主要フロー(典型フローとも呼ぶ)に指定する(ステップS149)。具体的には、モデルデータ格納部23のテーブルにおける主要フローフラグをオンにセットする。そして、全体に対して占める比率を算出し(ステップS151)、比率≧閾値であるか否か判断する(ステップS153)。この条件が満たされている場合にはステップS147に戻る。
例えば、図75の例では、最初に第1レコードを選択すると、全体に占める比率が50%となり、閾値が20%であれば、ステップS147に戻る。次に、第2レコードを選択すると、全体に占める比率は40%となり、同様に、ステップS147に戻る。このように第1レコード及び第2レコードについて主要フローフラグがオンにセットされる。
最後に、第3レコードを選択すると、全体に占める比率が10%となり、全体に占める比率≧閾値という条件が満たされなくなるので、プロセス表示処理部25は、元の処理に戻る。このようにすれば、ステップS147で選択されたプロセスインスタンスのグループ以外のプロセスインスタンスは、主要フローフラグがオンにセットされていないので、例外フローとして特定されたことになる。
図3の説明に戻って、プロセス表示処理部25は、モデルデータ格納部23に格納されているデータを用いて、入出力部11を介して処理結果を出力する(ステップS27)。例えば、全てのプロセスインスタンスを重ね合わせて表示する場合には、図56−2に示すような業務フローが表示されるようになる。この表示では、各イベントクラスを示す楕円は各1個のみ表示し、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため1本のみとしている。図56−2は、データ生成元の並列処理を含む業務フローと同じであり、システムのデータから、元の業務フローを復元できた例であることを示す。
また、モデルデータ格納部23に格納されている主要フローフラグのデータを用いて、主要フローと例外フローとを分けて表示する場合には、図77に示すような表示がなされる。例えば、80%を分類割合とすると、図75に示したテーブルにおいて第1及び第2レコードのプロセスインスタンスが重ね合わされて、図77の第1行目のような業務フローが主要フローとして表示される。主要フロー表示では、イベントクラス間の同一遷移を表す矢印は煩雑を避けるため1本のみとしている。また、図75に示したテーブルにおいて第3のプロセスインスタンスが、図77において第2行目の例外フローとして表示される。
以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、例えば図1A及び図1Bに示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュールに対応しない。
また、各スコア表も一例であって、確度スコア値の設定の仕方は、経験的にさらに細かく決定される場合もある。さらに、スコア表の項目についても、より少ない項目が設定される場合もあれば、より多くの項目が設定される場合もある。
また、図3の処理フローにおいて、ステップS7乃至S13については順番の入れ替えが可能であり、また並列に実施するようにしてもよい。
また、判定結果の出力では、各判定項目において「確定」判定や所定の閾値以上の確度スコアとなっているフィールドを自動的に選択してユーザに提示し、自動選択できない判定項目についてユーザに選択又は入力を促すようにしてもよい。
さらに、処理対象フィールドについてのループは、ステップS7乃至S13内の各々で構成されているが、ステップS7乃至S13の外側に処理対象フィールドについてのループを出すようにしてもよい。
なお、業務システム分析装置は、コンピュータ装置であって、図78に示すように、メモリ2501とCPU2503とハードディスク・ドライブ(HDD)2505と表示装置2509に接続される表示制御部2507とリムーバブル・ディスク2511用のドライブ装置2513と入力装置2515とネットワークに接続するための通信制御部2517とがバス2519で接続されている。オペレーティング・システム(OS:Operating System)及び本実施例における処理を実施するためのアプリケーション・プログラムは、HDD2505に格納されており、CPU2503により実行される際にはHDD2505からメモリ2501に読み出される。必要に応じてCPU2503は、表示制御部2507、通信制御部2517、ドライブ装置2513を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ2501に格納され、必要があればHDD2505に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク2511に格納されて頒布され、ドライブ装置2513からHDD2505にインストールされる。インターネットなどのネットワーク及び通信制御部2517を経由して、HDD2505にインストールされる場合もある。このようなコンピュータ装置は、上で述べたCPU2503、メモリ2501などのハードウエアとOS及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
以上本実施の形態をまとめると以下のようになる。
本業務フローデータ処理方法は、(A)特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各プロセスインスタンスに含まれるイベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、(B)統計情報格納部に格納されている各イベント間遷移発生頻度を、該当する発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、発側イベントクラスに属するイベントインスタンスが発生した場合に着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各イベントクラスに属するイベントインスタンスの発生頻度を全種のイベントクラスに属するイベントインスタンスの発生頻度の総和で除することによって、各イベントクラスに属するイベントインスタンスの発生確率を算出し、統計情報格納部に格納するステップと、(C)特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する条件付き確率と判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの発生確率とを用いて規定される評価式の値を、統計情報格納部に格納されている各イベント間遷移発生頻度に係る各遷移について算出し、統計情報格納部に格納するステップと、(D)統計情報格納部に格納されている、各遷移の評価式の値のうち所定の閾値未満となっている評価式の値に係る遷移を見かけ上遷移として検出するステップとを含む。
従来の方法に従えばイベントインスタンスを単純に発生日時で時系列に接続してプロセスインスタンスを生成してしまうので、主要経路と当該主要経路から分岐している並列経路とを含むような業務プロセスが実施される場合には問題が生ずる。すなわち、互いに並列関係にある部分フロー中のイベント間に業務フローに対応せず、見かけ上の遷移を誤設定するため、ユーザが業務フローを適切に把握できない。上で述べたような処理を実施することによって、並列経路に属するようなイベントインスタンスと主要経路に属するようなイベントインスタンスとの間の見かけ上遷移を統計的に検出することができるようになり、例えばユーザの確認の下採否を決定することができるようになる。
また、本方法は、プロセスインスタンスデータ格納部に格納されている各プロセスインスタンスについて、特定された見かけ上遷移に該当する遷移を含むか判断し、含む場合には見かけ上遷移に該当する遷移を削除して、見かけ上遷移の削除後のプロセスインスタンスのデータをデータ格納部に格納するステップをさらに含むようにしても良い。このようにすれば、自動的に実際の業務上は発生していないと推定される遷移を排除することができるようになる。
さらに、本方法は、データ格納部に格納されている、見かけ上遷移の削除後の各プロセスインスタンスに含まれる未接続イベントインスタンスの各々について、削除された見かけ上遷移の代わりに発生日時が最も近く且つ見かけ上遷移に該当しないイベントインスタンスを同一プロセスインスタンスにおいて検出して、検出された当該イベントインスタンスとの代替遷移を設定するステップをさらに含むようにしても良い。このように自動的に代替遷移を決定すれば、ユーザの負担を軽減することができる。但し、このように代替遷移を決定した後にさらに自動的に又は手動で修正するようにしても良い。
また、上で述べた評価式が、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの発生確率で除した値と1との差の絶対値を算出する式とする場合もある。このような評価式は、主要経路のイベントインスタンスと並列経路のイベントインスタンスとが独立に発生するという性質に基づくものであって、独立性が弱ければ大きな値となり、独立性が強ければ小さな値になる。
なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、CD−ROM、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
(付記1)
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出するステップと、
を、コンピュータに実行させるための業務フローデータ処理プログラム。
(付記2)
前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、特定された前記見かけ上遷移に該当する遷移を含むか判断し、含む場合には前記見かけ上遷移に該当する遷移を削除して、前記見かけ上遷移の削除後の前記プロセスインスタンスのデータをデータ格納部に格納するステップ
をさらにコンピュータに実行させるための付記1記載の業務フローデータ処理プログラム。
(付記3)
前記データ格納部に格納されている、前記見かけ上遷移の削除後の各前記プロセスインスタンスに含まれる未接続イベントインスタンスの各々について、削除された前記見かけ上遷移の代わりに発生日時が最も近く且つ前記見かけ上遷移に該当しないイベントインスタンスを同一プロセスインスタンスにおいて検出して、検出された当該イベントインスタンスとの代替遷移を設定するステップ
をさらにコンピュータに実行させるための付記2記載の業務フローデータ処理プログラム。
(付記4)
前記評価式が、
前記判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率を前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率で除した値と1との差の絶対値を算出する式である
付記1乃至3のいずれか1つ記載の業務フローデータ処理プログラム。
(付記5)
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納するステップと、
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納するステップと、
前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出するステップと、
を含み、コンピュータに実行される業務フローデータ処理方法。
(付記6)
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスに含まれる前記イベントインスタンス間の各遷移から、発側イベントクラスから着側イベントクラスへの遷移の発生頻度をイベント間遷移発生頻度として計数し、統計情報格納部に格納する手段と、
前記統計情報格納部に格納されている各前記イベント間遷移発生頻度を、該当する前記発側イベントクラスに属するイベントインスタンスの発生頻度で除することによって、前記発側イベントクラスに属するイベントインスタンスが発生した場合に前記着側イベントクラスに属するイベントインスタンスが発生する条件付き確率を算出すると共に、各前記イベントクラスに属するイベントインスタンスの発生頻度を前記イベントクラスに属する前記イベントインスタンスの発生頻度の総和で除することによって、各前記イベントクラスに属するイベントインスタンスの発生確率を算出し、前記統計情報格納部に格納する手段と、
特定の案件に関する業務処理中に実施された複数の業務イベントのイベントクラスのいずれかに属するイベントインスタンスを時系列に並べることにより作成したプロセスインスタンス中のイベント間遷移であって、当該イベント間遷移の発側イベント・着側イベントに対応する業務間に因果関係が無く独立して並列実施されているものを見かけ上遷移として検出するための評価式であって、判断対象となる遷移の発側イベントクラスに属するイベントインスタンスが発生した場合に当該判断対象となる遷移の着側イベントクラスに属するイベントインスタンスが発生する前記条件付き確率と前記判断対象となる遷移の着側イベントクラスに属するイベントインスタンスの前記発生確率とを用いて規定される評価式の値を、前記統計情報格納部に格納されている各前記イベント間遷移発生頻度に係る各前記遷移について算出し、前記統計情報格納部に格納する手段と、
前記統計情報格納部に格納されている、各前記遷移の前記評価式の値のうち所定の閾値未満となっている前記評価式の値に係る前記遷移を前記見かけ上遷移として検出する手段と、
を有する業務フローデータ処理装置。