JP4287234B2 - 業務プロセストラッキング装置，業務プロセストラッキング方法，業務プロセストラッキングプログラム，業務プロセストラッキングプログラムを記録した記録媒体 - Google Patents

Description

本発明は，複数の業務システムの間に流れる業務プロセスの追跡を行う業務プロセスの追跡技術に関し，特に，各業務システムから抽出したイベント情報を業務データ単位にまとめ，業務データを関連付けて管理し，入力された検索条件に基づいて業務プロセスをトラッキングする業務プロセストラッキング装置，業務プロセストラッキング方法，業務プロセストラッキングプログラム，業務プロセストラッキングプログラムを記録した記録媒体に関する。

稼動中の既存業務の改善を行う場合，どの部分に問題があり，改善したらよいかを判断するために，業務システム間の業務プロセスの分析が行われる。業務システム間の業務がどのように流れていくかを見るシステムとして，ワークフローシステムがある。ワークフローシステムとは，一般に，既存のフローエンジンを備え，定義されたフローに従った順序でシステムの自動実行を行うアプリケーションを備えるシステムを意味する。

図３７は，従来の一般的なワークフローシステムの概要を示す図である。２０はフロー管理サーバ，２１はアプリケーションＥ，２２はアプリケーションＦ，２３はアプリケーションＧ，２４はアプリケーションＨである。アプリケーションＥ２１〜Ｈ２４は，それぞれ異なるシステムに配置されている。２００はワークフローＥ，２０１はワークフローＦ，２０２はワークフローＧ，２０３はアプリケーションＥ２１〜Ｇ２３の実行履歴を管理するフロー管理サーバ２０内の履歴データベース（ＤＢ）である。

２１０はアプリケーションＥ２１の状態を管理する状態ＤＢ，２２０はアプリケーションＦ２２の状態を管理する状態ＤＢ，２３０はアプリケーションＧ２３の状態を管理する状態ＤＢ，２４０はアプリケーションＨ２４の状態を管理する状態ＤＢである。

また，アプリケーションＥ２１，アプリケーションＦ２２，アプリケーションＧ２３は，それぞれワークフローＥ２００，ワークフローＦ２０１，ワークフローＧ２０２から呼び出されて実行され，アプリケーションＨ２４は，上記ワークフローのいずれかから呼び出されて実行されるような実行形式を採らないものとする。

図３７に示すワークフローシステムでは，異なるシステム間の業務について，ワークフローＥ２００，ワークフローＦ２０１，ワークフローＧ２０２の順に流れることを定義しておいて，各ワークフローに対応するアプリケーションの実行履歴をフロー管理サーバ２０で管理する。すなわち，フロー管理サーバ２０は，ワークフローＥ２００に対応するアプリケーションＥ２１を実行し，アプリケーションＥ２１の実行終了後にワークフローＦ２０１に対応するアプリケーションＦ２２を実行し，アプリケーションＦ２２の実行終了後にワークフローＧ２０２に対応するアプリケーションＧ２３を実行する。

また，下記の特許文献１には，異なるシステムに跨るようなワークフローや非定型業務についても，その履歴や進行状態の管理情報を参照したり，辿ったりすることを可能にするワークフロー支援システムおよび支援方法について記載されている（特許文献１参照）。
特開平１０−６３７４７号公報

しかし，図３７に示すワークフローシステムは，あくまで各アプリケーションを順次実行していくという構成を採り，フロー管理サーバ２０において管理するのは各アプリケーションの実行履歴のみであったため，各アプリケーションの状態把握が困難である。このため，例えば，フロー管理サーバ２０がアプリケーションＥ２１中のいろいろな業務を管理するという要求に応えるためには，アプリケーションＥ２１の内部の処理を細分化して，フロー管理サーバ２０から呼び出して実行するなどの改造が必要となる。

また，例えば，アプリケーションＨ２４は，ワークフローＥ２００〜Ｇ２０２のいずれからも呼び出されて実行されるようにはなっていないため，フロー管理サーバ２０は，アプリケーションＨ２４の状態を把握できず，アプリケーションＨ２４の状態を把握するためには，アプリケーションＨ２４がワークフローから呼び出されて実行される形式に改造する必要がある。

さらに，現行のワークフローシステムでは，図３８に示すように，途中で複数に分岐するアプリケーションの関係を把握できないという問題がある。図３８において，例えば，ワークフローＦ２０１はワークフローＥ２００に関連した複数の処理をアプリケーションＦ２２とアプリケーションＦ’２２’に分けて実行させる。また，ワークフローＧ２０２は，ワークフローＦ２０１に関連した複数の処理を，それぞれアプリケーションＧ２３とアプリケーションＧ’２３’に分けて実行させる。アプリケーションＦ２２のデータ，アプリケーションＦ’２２’のデータは，アプリケーションＧ２３およびアプリケーションＧ’２３’の双方に渡されるものとする。

従来の一般的なワークフローシステムでは，アプリケーションＦ２２またはＦ’２２’と，アプリケーションＧ２３またはＧ’２３’との関係を把握することができない。このため，途中で複数に分岐するアプリケーションの関係を把握するためには，複数プロセスに分割して別々に分析するなど，業務プロセスと分析方法の見直しが必要であった。

また，上記特許文献１には，業務システム間の業務の流れの追跡結果をフロー形式で表示する技術については開示されていない。

特に，既存の多くの業務システムは，必ずしもフロー管理サーバ２０のようなフローエンジンのもとでワークフローに従って業務処理を遂行しているわけではなく，フロー管理サーバ２０が存在しないような場合には，業務の流れの追跡を行うためには，個々の業務システムにアクセスして処理済みデータ，未処理データなどのデータを収集し，分析しなければならないため，現実的には業務の流れの追跡は不可能であった。

本発明は，上記従来技術の問題点を解決し，異なる業務システム間を跨いで行われる複数のアプリケーションからなる業務プロセスの流れを，既存システムを変更することなく追跡できるようにすることを目的とする。

上記課題を解決するため，本発明は以下の処理を実行する。
（１）異なる業務システムに配置される各アプリケーションの実行状態を示す情報であるイベントデータを，各アプリケーションに応じた方法で収集し，イベントキューにキューイングする。

ここで，イベントとは，業務システム内で，ある業務が実行されたことを示すものであり，業務の開始，終了時間，および関連属性を含んだデータである。イベントデータは，各業務システムに配置されたイベント抽出定義に従って，各業務システム毎のイベントデータ抽出用のアプリケーションによって抽出される。各業務システム内で，抽出されたイベント情報を共通のＸＭＬ（extensible markup language）形式に変換し，イベントデータを管理するイベント管理装置のイベントキューにキューイングする。このキューイングには，例えばＪＭＳ（java message service）等が利用される。
（２）イベント管理装置内で，イベントキュー内にキューイングされたイベント情報について，業務データ毎にまとめ，業務データ間を関連付けてイベント管理データベース（ＤＢ）内に蓄積する。ここで，業務データとは，あるまとまった単位の業務の間で共有されるデータを意味する。
（３）入力された検索条件（例えば，イベント発生期間，関連属性等）に基づいて，業務データの絞込みを行う。
（４）絞り込まれた業務データに関連するデータをツリーで展開して表示し，任意のデータからの処理の追跡を行う。
（５）ツリーで展開された業務データに関連するイベントを検索し，このイベントに関連する業務をトラッキングビューで図示して，現在の業務の流れの実行状況を表示する。ここで，トラッキングとは，あらかじめ定義された業務システム間を跨ぐ業務全体の流れである業務プロセスのうち，どの業務が実行され，どの業務が実行されていないかを確認する手法をいう。

すなわち，本発明は，異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング装置であって，各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶する手段と，前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集するイベントデータ収集手段と，前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行うイベント関連付け手段と，前記関連付けられた業務データを蓄積するイベント管理データ記憶手段と，入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力する出力手段とを備え，前記イベント関連付け手段は，一の業務データの関連付け対象となる業務データが存在しないときには，該関連付け対象となる業務データを作成したうえで該一の業務データとの関連付けを行うことを特徴とする。

また，前記出力手段は，前記出力された業務データのツリー上で選択された業務データに関連するイベントを，前記業務プロセス定義情報に基づいて作成される業務プロセスの図上に表示する手段を備えることを特徴とする。

以上の各手段は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。

本発明によれば，異なる業務システム間を跨いで行われる複数のアプリケーションからなる業務プロセスの流れを既存システムを変更することなく追跡することが可能となる。特に，本発明によれば，個々のアプリケーションの状態を把握することができ，また，フロー管理されないアプリケーションの状態の把握も可能となる。また，本発明によれば，複数に分岐するアプリケーション間の関係の把握が可能となる。

図１は，本発明のシステム構成例を示す図である。図１において，１はイベントデータを収集し管理するイベント管理装置，３は業務システムＡ，４は業務システムＢ，５は業務システムＣ，６はユーザ端末である。

イベント管理装置１内において，１１はイベントデータの検索条件を入力する入力部，１２は業務システムＡ３〜業務システムＣ５から送信されたイベントデータがキューイングされるイベントキュー，１３はイベントキュー１２内のイベントデータを業務データ単位にまとめ，業務データ間の関連付けを行うイベント関連付け部，１４は関連付けられた業務データが蓄積されるイベント管理ＤＢ，１５は業務プロセスの定義情報と業務データの定義情報とが蓄積される業務プロセスＤＢである。１６はユーザ端末６から入力された検索条件に基づくイベント管理ＤＢ１４の検索結果を出力する出力部である。

業務プロセスとは，業務システム間を跨ぐ業務全体の流れを意味する。以下では，業務プロセスが，受注，在庫照会，発注，受入，出荷，配送等の業務から構成されるものとして説明する。また，業務データとは，前述したように，あるまとまった単位の業務の間で共有されるデータを意味する。業務データは，イベント管理ＤＢ１４内では，各業務の伝票という形で蓄積される。

業務システムＡ３内において，３０，３０’は，それぞれ業務システムＡ３内で業務を実行するアプリケーションＡ，アプリケーションＡ’，３１はアプリケーションＡ３０の状態が蓄積されている状態ＤＢ，３１’はアプリケーションＡ’３０’の状態が蓄積されている状態ＤＢ，３２は状態ＤＢ３１および状態ＤＢ３１’からイベントデータを抽出するイベント抽出部，３３は抽出したイベントデータを，例えばＸＭＬ形式に変換するイベントデータ変換部，３４は変換されたイベントデータをイベント管理装置１に送信するイベントデータ送信部，３２０は業務システムＡ３内のどのデータ項目を抽出するかを定義したイベント抽出定義のデータ（以下，単にイベント抽出定義という）である。

業務システムＢ４内において，４０，４０’は業務システムＢ４内で業務を実行するアプリケーションＢ，アプリケーションＢ’，４１はアプリケーションＢ４０の状態が蓄積されている状態ＤＢ，４１’はアプリケーションＢ’４０’の状態が蓄積されている状態ＤＢ，４２は状態ＤＢ４１または状態ＤＢ４１’からイベントデータを抽出するイベント抽出部，４３は抽出したイベントデータを，例えばＸＭＬ形式に変換するイベントデータ変換部，４４は変換されたイベントデータをイベント管理装置１に送信するイベントデータ送信部，４２０は業務システムＢ４内のどのデータ項目を抽出するかを定義したイベント抽出定義である。

業務システムＣ５内において，５０，５０’は業務システムＣ５内で業務を実行するアプリケーションＣ，アプリケーションＣ’，５１はアプリケーションＣ５０の状態が蓄積されている状態ＤＢ，５１’はアプリケーションＣ’５０’の状態が蓄積されている状態ＤＢ，５２は状態ＤＢ５１または状態ＤＢ５１’からイベントデータを抽出するイベント抽出部，５３は抽出したイベントデータを例えばＸＭＬ形式に変換するイベントデータ変換部，５４は変換されたイベントデータをイベント管理装置１に送信するイベントデータ送信部，５２０は業務システムＣ５内のどのデータ項目を抽出するかを定義したイベント抽出定義である。

イベント管理装置１のイベントキュー１２にキューイングされるイベントデータは，例えば，イベントの種別を示すイベント種別，イベントが属しているデータの識別子である主キー，主キーに対応する業務に関連する業務のイベントが属しているデータの識別子である関連キー，製造番号，個数，単価等の属性データから構成される。

業務システムＡ３〜業務システムＣ５は，例えば図２に示すように配置される。業務システムＡ３は，例えば，受注と在庫照会という業務を実行し，受注伝票３５を扱う。業務システムＢ４は，例えば，発注と受入という業務を実行し，発注伝票４５を扱う。業務システムＣ５は，例えば，出荷と配送という業務を実行し，配送伝票５５を扱う。

本発明による業務プロセスのトラッキングの準備として，業務プロセスＤＢ１５に格納する業務プロセスおよび業務データの定義情報の入力，および各業務システムＡ〜Ｃのイベント抽出部３２〜５２に設定するイベント抽出定義３２０〜５２０の入力が必要となる。これらの定義情報の入力方法について説明する。

図３および図４は，業務プロセスＤＢ１５内に格納する定義データの入力画面を示す図である。例えば，あらかじめ用意されたツールボックス（図示省略）のグラフィカルユーザインタフェース（ＧＵＩ）を用いることにより，図３の点線で囲った部分に示すような業務プロセスを描画すると，業務プロセスに関する定義データが生成され，業務プロセスＤＢ１５内に蓄積される。図３に示す入力画面では，例えばアクティビティとして「＜＜販売＞＞受注」の次に「＜＜販売＞＞在庫照会」が実行され，続いて，在庫がない場合には，「＜＜購買＞＞発注」，「＜＜購買＞＞受入」のアクティビティが実行され，在庫がある場合には，「＜＜販売＞＞出荷」，「＜＜配送＞＞配送」のアクティビティが実行されることが定義されている。

また，図４に示す入力画面上で，「受注」，「発注」，「配送」という業務データとその間の関係を描画することにより，各業務データが生成され，業務プロセスＤＢ１５内に蓄積される。図４に示す入力画面では，例えば，業務データ「受注」の属性データとして「受注ＩＤ」や「納品日」等のデータがあり，業務データ「発注」の属性データとして「発注ＩＤ」や「受注ＩＤ」等のデータがあり，業務データ「配送」の属性データとして「配送ＩＤ」や「発注ＩＤ」等のデータがあることが定義されている。このように，業務データ内に他の業務データのＩＤを持つことで，業務データ間の関連付けが行われる。

図３および図４の入力画面から入力された定義情報に基づいて，図５および図６に示すような定義データが自動生成される。この例では，業務プロセスの定義データがリレーショナルデータベースのテーブルとして生成され管理されている。図５および図６は，業務プロセスＤＢ１５内に格納する定義データのデータ構成を示す図である。

図５（Ａ）は業務プロセスを構成する各業務であるアクティビティのテーブルの例を示している。図５（Ａ）に示すように，業務プロセスは，例えば，受注，在庫照会，発注，受入，出荷，配送といったアクティビティから構成されることが定義され，各アクティビティには，それらの各々を一意に特定するＩＤが付与される。また，図５（Ｂ）は，業務データのテーブルの例を示している。例えば，業務データのテーブルには，業務データとして受注，発注，配送があることが定義され，それぞれに各業務データを一意に特定するＩＤが定義されている。

図６（Ａ）は，業務データ内の属性データを示す図である。例えば，受注という業務データ（ＩＤ＝ｄ１）の属性データは，受注ＩＤと納品日と受注金額であり，発注という業務データ（ＩＤ＝ｄ２）の属性データは，発注ＩＤと受注ＩＤと発注先であり，配送という業務データ（ＩＤ＝ｄ３）の属性データは，配送ＩＤと発注ＩＤと配送日であることが定義されている。

上記のように，例えば，発注という業務データの属性データとして受注ＩＤが定義され，また，配送という業務データの属性データとして発注ＩＤが定義されることにより，発注は受注に対する関連を持ち，配送は発注に関連を持つこととなる。これは，上記図４において描画された「配送」→「発注」→「受注」という各業務データ間の関係に対応するものである。

図６（Ｂ）は，アクティビティと業務データとの対応表を示す図である。この対応表は，ＩＤ，入出力，効果，アクティビティ，業務データという項目から構成される。効果の項目の「Ｃ」はCreate，「Ｒ」はRead，「Ｕ」はUpdateを意味する。

例えば，この対応表の第１行目を見ると，受注というアクティビティから受注という業務データが出力され，その遷移のＩＤはｔ１であることが分かる。第２行目では，在庫照会というアクティビティに受注という業務データが入力され，その遷移のＩＤはｔ２であることが分かる。また，第３行目では，発注というアクティビティから発注という業務データが出力され，その遷移のＩＤはｔ３であることが分かる。第４行目では，受入というアクティビティに発注という業務データが入力され，その遷移のＩＤはｔ４であることが分かる。第５行目では，出荷というアクティビティから配送という業務データが出力され，その遷移のＩＤはｔ５であることが分かる。第６行目では，配送というアクティビティに配送という業務データが入力され，その遷移のＩＤはｔ６であることが分かる。

図３〜図６で説明した業務プロセスの定義の後，各業務システムでどのようなイベントを監視し抽出するかのイベント抽出定義を入力する。図７および図８は，各業務システム内のイベント抽出定義を生成するためのイベント抽出定義画面の一例を示す図である。図７（Ａ）は業務プロセスの選択画面を示す。

図７（Ａ）においてプロセス項目として製造プロセスが選択され，「次へ」のボタンが押されると，図７（Ｂ）に示すように，アクティビティの選択画面が表示される。このアクティビティの選択画面において，例えばアクティビティとして「＜＜販売＞＞受注」が選択され，「次へ」のボタンが押されると，図８（Ａ）に示すように，「＜＜販売＞＞受注」というアクティビティを実行する業務システムの選択画面が表示される。

業務システムとして「業務システムＡ」が選択され，「次へ」のボタンが押されると，図８（Ｂ）に示すように，選択されたアクティビティのデータ項目に対応する業務システムＡ３内のデータ項目の選択画面が表示される。図８（Ｂ）に示す選択画面に従ってシステム内データ項目が選択され，「設定」のボタンが押されると，例えば，図９に示すようなイベント抽出定義３２０が生成される。図９に示すイベント抽出定義３２０には，例えば，選択された業務システムＡ３のシステム名（system name ）として“ｍｙＲ３”が，アクティビティ名（activity Name ）として“受注”が，主キー名（primaryKey name ）として“受注”が記述され，図８（Ｂ）に示す選択画面に従って選択された業務システムＡ３内のデータ項目である“受注金額”，“納品希望日”が，属性名（property name ）として記述される。

図１０は，イベント抽出定義の配置例を示す図である。図１０に示すように，例えば，業務システムＡ３のイベント抽出部３２は，受注抽出定義３２０−１と在庫照会抽出定義３２０−２とを有し，業務システムＢ４のイベント抽出部４２は，発注抽出定義４２０−１と受入抽出定義４２０−２とを有し，業務システムＣ５のイベント抽出部５２は，出荷抽出定義５２０−１と配送抽出定義５２０−２とを有する。

業務システムＡ３のイベント抽出部３２は，受注抽出定義３２０−１に従って，業務システムＡ３内の受注業務を実行するアプリケーションＡ３０の状態を管理する状態ＤＢ３１からイベントデータを抽出する。抽出されるイベントデータのイベント種別は受注であり，主キーは受注伝票３５のＩＤである。

また，在庫照会抽出定義３２０−２に従って，業務システムＡ３内の在庫照会業務を実行するアプリケーションＡ’３０’の状態を管理する状態ＤＢ３１’からイベントデータを抽出する。抽出されるイベントデータのイベント種別は在庫照会であり，主キーは受注伝票３５のＩＤである。

業務システムＢ４のイベント抽出部４２は，発注抽出定義４２０−１に従って，業務システムＢ４内の発注業務を実行するアプリケーションＢ４０の状態を管理する状態ＤＢ４１からイベントデータを抽出する。抽出されるイベントデータのイベント種別は発注であり，主キーは発注伝票４５のＩＤ，関連キーは業務システムＡ３が扱う受注伝票３５のＩＤである。

また，受入抽出定義４２０−２に従って，業務システムＢ４内の受入業務を実行するアプリケーションＢ’４０’の状態を管理する状態ＤＢ４１’からイベントデータを抽出する。抽出されるイベントデータのイベント種別は受入であり，主キーは発注伝票４５のＩＤである。

業務システムＣ５のイベント抽出部５２は，出荷抽出定義５２０−１に従って，業務システムＣ５内の出荷業務を実行するアプリケーションＣ５０の状態を管理する状態ＤＢ５１からイベントデータを抽出する。抽出されるイベントデータのイベント種別は出荷であり，主キーは配送伝票５５のＩＤ，関連キーは業務システムＢ４が扱う発注伝票４５のＩＤである。

また，配送抽出定義５２０−２に従って，業務システムＣ５内の配送業務を実行するアプリケーションＣ’５０’の状態を管理する状態ＤＢ５１’からイベントデータを抽出する。抽出されるイベントデータのイベント種別は配送であり，主キーは配送伝票５５のＩＤである。

イベント抽出部３２〜５２の実現方法としては，業務システムのアプリケーションに応じて各種の方法を用いることができる。例えばＳＡＰ（service access point）／Ｒ３用イベントデータの抽出定義を用意することで，ユーザ出口ルーチンを自動的に生成し，そのモジュールを用いてイベントの抽出を行う。また，アプリケーションがリレーショナルデータベース（ＲＤＢ）を用いているような場合には，ＲＤＢ用イベントデータの抽出定義を用意することで，ＲＤＢのトリガモジュールを自動的に生成し，それによってイベントの抽出を行うようなこともできる。

業務システムＡ３〜業務システムＣ５において抽出された各イベントデータは，各業務システム内のイベントデータ変換部３３，４３，５３によって，例えば図１１（Ａ）に示す受注イベントデータや図１１（Ｂ）に示す発注イベントデータのように，ＸＭＬ形式に変換され，イベントデータ送信部３４，４４，５４によってイベント管理装置１に送信される。

図１に示すイベント管理装置１のイベントキュー１２には，業務システムＡ３〜業務システムＣ５から，各業務システム内で業務を実行する各アプリケーションに応じた方法で抽出され送信されたイベントデータがキューイングされる。

イベント管理装置１のイベント関連付け部１３は，イベントキュー１２中のイベントデータを業務データ単位でまとめ，業務データ間の関連付けを行い，イベント管理ＤＢ１４に蓄積する。例えば，図１２に示すように，業務データの関連付けの結果，業務データＡと業務データＡ’に関連するデータは業務データＢと業務データＢ’であり，業務データＢに関連するデータは業務データＣであり，業務データＢ’に関連するデータは業務データＣ’となる。

出力部１６は，詳しくは後述するように，ユーザ端末６から入力された検索条件（例えば，業務プロセス名や伝票番号等）に基づくイベント管理ＤＢ１４の検索結果を出力する。ユーザ端末６は，イベント管理ＤＢ１４の検索結果を解釈し表示するイベントエクスプローラを備えており，ユーザは，このイベントエクスプローラを用いてイベント管理装置１にアクセスし，ユーザ端末６上に検索結果を表示させることができるようになっている。また，出力部１６は，上記検索結果として表示された業務データのうち，選択された業務データに関連するイベントをユーザ端末６上にフロー形式で表示して，業務システム間に流れている業務の実行状況を表示する機能を持つ。

ユーザ端末６は，ネットワークを介してｈｔｔｐプロトコルを用いたＷｅｂアクセスによりイベント管理装置１にアクセスする機能を持つ。ユーザ端末６は，１台に限らず何台あってもよい。

図１３は，業務プロセスＤＢ１５内のデータから生成するフロー表示用ＳＶＧ（scalable vector graphic ）ファイルの例である。ＳＶＧは，画像をＸＭＬで表現するための標準的な言語であり，ＳＶＧファイルには，この言語を用いて図１３に示すように２次元グラフィックスを記述したデータが格納されている。このＳＶＧファイルは，ベクターデータ内に識別ＩＤを埋め込んだ形になっている。

図１４は，イベント管理装置１における処理フローの概要を示す図である。まず，各業務システムから受信したイベントデータをイベントキュー１２に蓄積する（ステップＳ１）。次に，イベント関連付け部１３が，イベントデータを業務データ単位にまとめ，業務データの関連付け処理を行う（ステップＳ２）。そして，関連付けられた業務データをイベント管理ＤＢ１４に蓄積する（ステップＳ３）。

ユーザ端末６から検索条件が入力されると，出力部１６は，ユーザ端末６から入力された検索条件に基づいてイベント管理ＤＢ１４を検索し，その検索結果を出力する（ステップＳ４）。上記検索結果として表示された業務データのうち，ある業務データをユーザが選択すると，選択された業務データに関連するイベントをユーザ端末６上に表示する（ステップＳ５）。表示終了の指示があれば，処理を終了する。

図１５は，業務データの関連付け処理フローを示す図である。イベント関連付け部１３は，イベントデータのキューイングを検知すると（ステップＳ２１），イベント管理ＤＢ１４内に主キーに対応する業務データ（主業務データという）が存在するかを判断し（ステップＳ２２），主業務データが存在しない場合は主業務データを作成し（ステップＳ２３），ステップＳ２４に移行する。

例えば，図１６（Ａ）に示すＸＭＬ形式のイベントデータ「イベント名：受注，主キー（発注伝票ＩＤ）：ｐ１０１，関連キー（受注伝票ＩＤ）：ｏ００１，開始時刻：２００３年８月２７日１０：００，属性（単価）：１０００」を受信すると，イベント管理ＤＢ１４内に「主キー：ｐ１０１」に対応する主業務データがあるかを判断し，なければ主業務データとして発注伝票を作成する。例えば，図１６（Ｂ）に示すような発注伝票が作成される。

イベント管理ＤＢ１４内に主業務データが存在する場合には，主業務データにイベントとイベントからとった属性を追加する（ステップＳ２４）。例えば，図１６（Ｂ）の発注伝票中の「<bpm:eventName> 発注</bpm:eventName>」，「<bpm:startTime>20030827T1000</bpm:startTime>」のように，発注伝票にイベントとして「発注」というイベント名と，「２００３年８月２７日１０：００」という開始時刻を追加する。また，発注伝票中の「<bpm:property name="単価">1000</bpm:property> 」のように，属性として「１０００」という単価を追加する。

次に，イベントデータに関連キーがあるかを判断する（ステップＳ２５）。関連キーがあれば，イベント管理ＤＢ１４内に関連キーに対応する業務データ（関連業務データという）が存在するかを判断する（ステップＳ２６）。

イベント管理ＤＢ１４内に関連業務データが存在しない場合には，関連業務データを作成し（ステップＳ２７），ステップＳ２８に移行する。例えば，図１６（Ｃ）に示すように，関連業務データとして受注伝票が作成される。

関連業務データが存在する場合には，主業務データから関連業務データへの関連を追加する（ステップＳ２８）。例えば，図１６（Ｂ）に示す発注伝票中の「<bpm:relativeKey type=" 受注伝票">o001</bpm:relativeKey>」のように，発注伝票中に受注伝票ＩＤの「ｏ００１」が記述され，受注伝票への関連が追加される。

また，関連業務データから主業務データへの関連を追加する（ステップＳ２９）。例えば，図１６（Ｃ）に示す受注伝票中の「<bpm:relativeKey type=" 発注伝票">p001</bpm:relativeKey>」のように，受注伝票中に発注伝票ＩＤの「ｐ１０１」が記述され，発注伝票への関連が追加される。

図１７は，業務データの関連付け処理を説明する模式図である。イベント管理装置１のイベントキュー１２中にイベントデータがキューイングされる。キューイングされたイベントデータは，例えば，イベント種別（またはイベント名），主キーデータ種別，主キー，関連キーデータ種別，関連キー，関連属性，発生時刻といった要素から構成される。

イベント関連付け部１３が，上記図１５で説明した業務データの関連付け処理フローに従って業務データの関連付けを行う。その結果，イベント管理ＤＢ１４内に図１７に示すような業務データが作成される。図１７の点線で示す矢印は，イベントデータ中の各要素とイベント管理ＤＢ１４中に作成される業務データとの対応を示す。

図１７において，イベント関連付け部１３は，主データ項目をたててデータ種別，主キーを格納することにより，主キーに対応する主業務データを作成する。そして，主業務データ中にイベントとしてイベント種別と時刻を追加し，また，関連属性を追加する。イベントデータ中に関連キーがあれば，関連データ項目を立ててデータ種別と関連キーを格納して関連業務データを作成する。そして，主業務データ中に，リンク先情報としてデータ種別，関連キーを格納して，関連業務データへの関連を追加する。また，関連業務データ中にも，リンク先情報としてデータ種別，主キーを格納して，主業務データへの関連を追加する。

図１７に示すように，イベントデータとして取得する業務データ間の関連をもとに，あらかじめ業務データ間に双方向参照を作成することにより，後述する出力部１６による検索処理において，トラッキング速度を改善することができる。

図１８は，受注イベントデータと在庫照会イベントデータと発注イベントデータを受信した場合の業務データの関連付けの例を示している。上記図１５で説明した業務データの関連付け処理の結果，イベント管理ＤＢ１４中に図１８に示すような受注伝票と発注伝票が作成される。この受注伝票には，イベントとして「受注」と「在庫照会」が格納され，また，関連キーとして発注伝票ＩＤの「ｐ１０１」が記述され，発注伝票への関連が追加されている。また，発注伝票にも関連キーとして受注伝票ＩＤの「ｏ００１」が記述され，受注伝票への関連が追加されている。

図１９は，初めにイベント管理ＤＢ１４内にデータがない場合の業務データ（伝票）の作成処理の例を示す図である。図１９（Ａ）に示すように，イベント管理ＤＢ１４内にデータがない場合に，イベントデータＡとイベントデータＢがイベントキュー１２にキューイングされたとすると，イベント関連付け部１３は，イベントデータＡとイベントデータＢとに基づいて図１９（Ｂ）に示すような受注伝票を作成する。

すなわち，イベントデータＡ中の主キー「ｏ００１」に対応する主業務データとして受注伝票を作成し，イベントとして，「イベント名：受注入力」，「開始時刻：２００３年８月２７日１１：００」，「終了時刻：２００３年８月２７日１２：００」を追加し，「属性名：製品」と「属性：ａｂｃ」，および「属性名：数量」と「属性：１０」を追加する。

図２０は，イベント管理ＤＢ１４内に既に図２０（Ａ）に示す受注伝票が作成されている場合の業務データ（伝票）の作成処理の例を示す図である。イベント管理ＤＢ１４内に図２０（Ａ）に示すような受注伝票が作成されている場合に，イベントデータＣとイベントデータＤがイベントキュー１２にキューイングされると，イベント関連付け部１３は，イベントデータＣとイベントデータＤとに基づいて，図２０（Ｂ）に示すような受注伝票を作成する。

すなわち，イベント関連付け部１３は，図２０（Ａ）に示す受注伝票中に，イベントとして，「イベント名：在庫照会」，「開始時刻：２００３年８月２７日１３：００」，「終了時刻：２００３年８月２７日１４：００」を追加して，図２０（Ｂ）に示す新たな受注伝票を作成する。

図２１は，イベント管理ＤＢ１４内に図２１（Ａ）に示すような受注伝票が作成されている場合の業務データ（伝票）の作成処理の例を示す図である。イベント管理ＤＢ１４内に図２１（Ａ）に示すような受注伝票が作成されている場合に，イベントデータＥとイベントデータＦがイベントキュー１２にキューイングされると，イベント関連付け部１３は，イベントデータＥとイベントデータＦとに基づいて図２１（Ｂ）に示すような受注伝票と配送伝票を作成する。

すなわち，イベント関連付け部１３は，イベントデータＥ中の主キーの「ｄ００１」に対応する主業務データとして配送伝票を作成し，イベントとして，「イベント名：出荷」，「開始時刻：２００３年８月２７日１７：００」，「終了時刻：２００３年８月２７日１８：００」を追加し，「属性名：地域」，「属性：川崎」を追加する。また，作成した配送伝票中に，「<bpm:relativeKey type=" 受注">o001</bpm:relativeKey>」を記述することにより，受注伝票への関連を追加するとともに，受注伝票中に「<bpm:relativeKey type=" 配送">d001</bpm:relativeKey>」を記述することにより，配送伝票への関連を追加する。

図２２ないし図２７は，複数の業務システムからのイベント収集の流れを説明する図である。図２２に示すように，例えば，業務システムＡ３において斜線で示す受注業務が終了した際にイベント抽出部３２が抽出したイベントデータ「イベント名：受注，主伝票：受注，主キー：ｏ００１，開始時刻：１０：００，終了時刻：１０：３０」が，イベント管理装置１のイベントキュー１２内にキューイングされると，イベント管理ＤＢ１４の中に，斜線で示すように，主データ項目として「受注：ｏ００１」が記述されて受注伝票が作成される。また，作成された受注伝票に，斜線で示すように，「イベント名：受注」，「開始時刻：１０：００，終了時刻：１０：３０」というイベントが追加される。

図２３に示すように，業務システムＡ３において斜線で示す在庫照会業務が終了した際に，イベント抽出部３２が抽出したイベントデータ「イベント名：在庫照会，主伝票：受注，主キー：ｏ００１，開始時刻：１０：３０，終了時刻：１１：００」が，イベントキュー１２内にキューイングされると，このイベントデータの内容に基づいて，斜線で示すように，既に作成されている受注伝票の中に「イベント名：在庫照会，開始時刻：１０：３０，終了時刻：１１：００」というイベントが追加される。

また，図２４に示すように，業務システムＢ４において斜線で示す発注業務が終了した際にイベント抽出部４２が抽出したイベントデータ「イベント名：発注，主伝票：発注，主キー：ｐ１０１，関連伝票：受注，関連キー：ｏ００１，開始時刻：１１：００，終了時刻：１１：３０」が，イベントキュー１２内にキューイングされると，以下のようにして業務データ（伝票）の関連付けが行われる。

まず，主データ項目として斜線で示す「発注：ｐ１０１」をたてて，主キー「ｐ１０１」に対応する発注伝票を作成する。そして，作成した発注伝票中に，「イベント名：発注，開始時刻：１１：００，終了時刻：１１：３０」というイベントを追加する。イベントデータ中には，関連キーとして受注伝票ＩＤの「ｏ００１」が記述されているので，発注伝票の中に斜線で示す受注伝票ＩＤの「ｏ００１」を記述し，受注伝票との関連付けを行う。また，受注伝票の中に斜線で示す発注伝票ＩＤの「ｐ１０１」を記述し，受注伝票へとの関連付けを行う。

また，図２５に示すように，業務システムＢ４において斜線で示す受入業務が終了した際に，イベント抽出部４２が抽出したイベントデータ「イベント名：受入，主伝票：発注，主キー：ｐ１０１，開始時刻：１１：３０，終了時刻：１２：００」が，イベントキュー１２内にキューイングされると，このイベントデータの内容に基づいて，既に作成されている発注伝票の中に斜線で示す「イベント名：受入，開始時刻：１１：３０，終了時刻：１２：００」というイベントが追加される。

また，図２６に示すように，業務システムＣ５において斜線で示す出荷業務が終了した際に，イベント抽出部５２が抽出したイベントデータ「イベント名：出荷，主伝票：配送，主キー：ｄ２０１，関連伝票：発注，関連キー：ｐ１０１，開始時刻：１２：００，終了時刻：１２：３０」が，イベントキュー１２内にキューイングされると，以下のようにして業務データ（伝票）の関連付けが行われる。

まず，主データ項目として「配送：ｄ２０１」をたてて，主キー「ｄ２０１」に対応する配送伝票を作成する。そして，「イベント名：出荷，開始時刻：１２：００，終了時刻：１２：３０」というイベントが追加される。さらに，イベントデータ中には，関連キーとして発注伝票ＩＤの「ｐ１０１」が定義されているので，配送伝票の中に斜線で示す発注伝票ＩＤの「ｐ１０１」を記述し，発注伝票との関連付けを行う。また，発注伝票の中に斜線で示す配送伝票ＩＤの「ｄ２０１」を記述し，配送伝票へとの関連付けを行う。

また，図２７に示すように，業務システムＣ５から斜線で示す配送業務が終了した際に，イベント抽出部５２が抽出したイベントデータ「イベント名：配送，主伝票：配送，主キー：ｄ２０１，開始時刻：１２：３０，終了時刻：１３：００」が，イベントキュー１２内にキューイングされると，このイベントデータの内容に基づいて，既に作成されている配送伝票の中に斜線で示す「イベント名：配送，開始時刻：１２：３０，終了時刻：１３：００」というイベントが追加される。

図２８および図２９は，ユーザ端末６における業務データの検索条件入力画面の例を示す図である。ユーザは，図２８に示す検索条件入力画面を利用して，どのデータに注目して業務の流れをトラッキングするかについての条件をイベント管理装置１に入力する。

図２８に示す検索条件入力画面の例では，業務プロセスとして「ｓａｍｐｌｅ１」，検索対象として「配送」伝票が選択され，検索項目として「伝票番号」，検索範囲として「２００３年１月１日〜２００３年１０月１日」が選択されている。また，結果表示方法として，「イベントエクスプローラで表示」が選択されている。「検索実行」が押されると，イベント管理装置１内のイベント管理ＤＢ１４の検索が開始される。検索結果の表示例については，図３１，図３２，図３３を用いて説明する。

図２９は，検索条件入力画面において検索結果の表示方法として「一覧で表示」を選択した場合の例を示す図である。この例では，業務プロセスとして「製造販売」，検索対象として「受注」，検索範囲として「２００３年１月１日〜２００３年１月１日」が選択されている。さらに，結果表示方法として「一覧で表示」が選択され，「検索実行」が押されると，例えば図３０に示すような検索結果が表示される。この例では，検索結果として伝票番号「ｏ００２，ｏ００１，ｏ０１１」が表示されている。

図３１は，業務プロセスのトラッキング過程における操作と表示の一例を示す図である。ここでは，検索条件入力画面において選択された業務プロセスが「製品プロセス」である場合の例を示している。イベント管理ＤＢ１４が検索された結果，例えば，図３１（Ａ）に示すように，ユーザ端末６のイベントエクスプローラの表示領域に受注伝票の主データ項目である「受注：ｏ００１」が表示され，その横に製品プロセスが表示される。このイベントエクスプローラの領域に表示された「＋受注：ｏ００１」は，「受注：ｏ００１」というノードが閉じていること，すなわち，受注伝票の主データ項目が選択されていないことを示している。

次に，表示されたイベントエクスプローラを利用して「受注：ｏ００１」が選択されると，受注伝票の主データ項目が選択されたことから，図３１（Ｂ）に示すように，「受注：ｏ００１」というノードが開いて「−受注：ｏ００１」と表示され，関連する業務データである配送伝票への関連データ「＋配送：ｄ００１」が表示される。「受注：ｏ００１」が選択されたことにより，受注伝票に関連する「受注入力」のイベントと「在庫照会」のイベントが検索され，イベントエクスプローラの横に表示された製品プロセスにおいて，例えば，網かけ部に示すように，両イベントに関連するアクティビティの色が変更されて表示される。色を変えるのではなく，文字，線の太さなどの属性を変化させて表示してもよい。これは，あらかじめフローの図示に用いるデータをＳＶＧ（scalable vector graphic ）で作成し，ＳＶＧ内のオブジェクトの色，文字，線の太さなどの属性を変化させることで簡易に実現することができる。

次に，図３１（Ｂ）に示す「＋配送：ｄ００１」が選択されると，図３１（Ｃ）のイベントエクスプローラの領域に示すように，「配送：ｄ００１」というノードが開いて，「−配送：ｄ００１」という表示に変わる。そして，選択された「配送：ｄ００１」に関連する「出荷」のイベントが検索され，製品プロセスにおいて，例えば，網かけ部に示すように，「出荷」のイベントに関連するアクティビティの色が変更されて表示される。

図３２は，業務プロセスの逆トラッキング過程における操作と表示の一例を示す図である。イベント管理ＤＢ１４が検索された結果，例えば，図３２（Ａ）に示すように，ユーザ端末６のイベントエクスプローラの表示領域に配送伝票の主データ項目である「配送：ｄ００１」が表示され，その横に，検索対象である製品プロセスが表示されたとする。このイベントエクスプローラの画面で「配送：ｄ００１」が選択されると，配送伝票の主データ項目が選択されたことから，図３２（Ｂ）に示すように，「配送：ｄ００１」というノードが開いて「−配送：ｄ００１」と表示され，関連する業務データである受注伝票への関連データ「＋受注：ｏ００１」が表示される。「配送：ｄ００１」が選択されたことにより，配送伝票に関連する「出荷」のイベントが検索され，図３２（Ｂ）に示す製品プロセスにおいて，例えば，網かけ部に示すように，「出荷」のイベントに関連するアクティビティの色が変更されて表示される。

次に，図３２（Ｂ）に示す「＋受注：ｏ００１」が選択されると，図３２（Ｃ）のイベントエクスプローラの領域に示すように，「受注：ｏ００１」というノードが開いて，「−受注：ｏ００１」という表示に変わる。そして，選択された「受注：ｏ００１」に関連する「受注入力」のイベントと「在庫照会」のイベントが検索され，図３２（Ｃ）に示す製品プロセスにおいて，例えば，網かけ部に示すように，これらのイベントに関連するアクティビティの色が変更されて表示される。このようにイベントを順次さかのぼる逆トラッキングも可能である。

図３３は，業務プロセスのトラッキング結果画面の例を示す図である。ここでは，検索条件入力画面において，業務プロセスとして「ｓａｍｐｌｅ１」，検索対象として「配送」，検索範囲として「２００３年１月１日〜２００３年１０月１日」が選択された場合の検索結果と表示される業務プロセスを示す。

図３３のイベントエクスプローラの表示領域に示すように，配送伝票の主データ項目である「配送：ｄ２０１」が選択されたことから，配送伝票に関連する「出荷」のイベントと「配送」のイベントが検索され，業務プロセスのトラッキング結果として，この「出荷」のイベントと「配送」のイベントに関連するアクティビティが，網かけ部に示すように色が変更されて表示される。

図３４は，イベントエクスプローラの表示処理フローを示す図である。まず，未処理の検索結果が存在するかを判断し（ステップＳ３１），未処理の検索結果が存在する場合には，ユーザ端末６から入力された検索条件に基づいて，検索結果データを取得する（ステップＳ３２）。例えば，図３１（Ａ）に表示されるイベントエクスプローラにおいて，検索結果データとして「受注：ｏ００１」が取得される。

次に，取得された検索結果データが選択されているかを判断する（ステップＳ３３）。検索結果データが選択されていない場合には，閉じたノードを描画し（ステップＳ３４）ステップＳ３１に戻る。例えば，上述した図３１（Ａ）に示す「＋受注：ｏ００１」のように描画する。

検索結果データが選択されている場合には，開いたノードを描画する（ステップＳ３５）。例えば，図３１（Ｂ）に示す「−受注：ｏ００１」のように描画する。次に，関連データが存在するかを判断し（ステップＳ３６），関連データが存在しなければステップＳ３１に戻る。関連データが存在すれば関連データを取得する（ステップＳ３７）。次に，関連データが選択されているかを判断し（ステップＳ３８），選択されていなければ閉じたノードを描画して（ステップＳ３９），ステップＳ３６に戻る。例えば，図３１（Ｂ）において，選択された「受注：ｏ００１」の関連データとして取得された「配送：ｄ００１」を，「＋配送：ｄ００１」のように描画する。

関連データが選択されている場合には，開いたノードを描画する（ステップＳ４０）。例えば，図３１（Ｃ）に示す「−配送：ｄ００１」のように描画する。未処理の検索結果が存在しなくなった場合には，編集したビュー（全体の画面）を出力して（ステップＳ４１），処理を終了する。

図３５は，業務プロセスのトラッキング表示処理フローを示す図である。まず，選択済み子ノードが存在するかを判断する（ステップＳ５１）。例えば，図３３に表示されたイベントエクスプローラにおいて，「−」のついたデータが存在するかを判断する。図３３に示すイベントエクスプローラの表示例では，「配送：ｄ２０１」が選択済みであることが分かる。次に，選択された子ノードのデータを特定し（ステップＳ５２），特定されたデータに関連するイベント情報を取得する（ステップＳ５３）。例えば，選択された「配送：ｄ２０１」に関連する「出荷」のイベント情報と「配送」のイベント情報が取得される。

次に，未処理イベント情報が存在するかを判断する（ステップＳ５４）。未処理イベント情報が存在する場合には，イベントに対応するアクティビティの色を変更する（ステップＳ５５）。例えば，図３３に示す業務プロセスにおいて，網かけ部に示すように，「出荷」と「配送」というイベントに関連するアクティビティの色が変更される。そして，指定された属性値を表示して（ステップＳ５６），ステップＳ５３に戻る。ステップＳ５４で未処理イベント情報が存在しない場合には，ステップＳ５１へ戻り，選択済み子ノードが存在しなければビュー出力し（ステップＳ５７），処理を終了する。

図３６は，アラート表示画面の例を示す図である。ユーザ端末６からアラート表示をする対象となる業務プロセスやアラート種別等が選択入力されることにより，イベント管理装置１の出力部１６は，アラート表示を出力する。

図３６に示す例では，アラート種別として全てのアラートが選択され，業務プロセスとして「ｓａｍｐｌｅ１」が指定された場合に，斜線部に示すように，アクティビティのうち「配送」が納期遅れであることを通知するアラート表示（例えば，色の変更）がされる。アラート表示を行う条件は，あらかじめ業務プロセスＤＢ１５に業務プロセス定義情報を登録する際に定義しておくことができる。すなわち，各イベントとしての業務データの標準処理時間をあらかじめ定義しておくことで，標準処理時間に対する遅れ度，特定のイベントが完了するまでの予測時間を図示することができる。

例えば，定義した標準処理時間に基づいて算出したイベント完了の予測時間をもとに，遅れると予想される伝票を業務プロセスの図上に表示したり，またその伝票の担当者にメールやその他の手段により通知するようなことも可能である。このように，本発明によれば，イベント管理ＤＢ１４に全ての業務システムＡ３〜Ｃ５におけるイベント情報が関連付けられて格納されているので，イベント管理ＤＢ１４のデータを監視することにより，必要な場合にはアラート表示を簡易に行うことができる。

以上から把握できるように，本発明の実施形態の特徴を述べると，以下のとおりである。

（付記１） 異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング装置であって，
各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶する手段と，
前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集するイベントデータ収集手段と，
前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行うイベント関連付け手段と，
前記関連付けられた業務データを蓄積するイベント管理データ記憶手段と，
入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力する出力手段とを備える
ことを特徴とする業務プロセストラッキング装置。

（付記２） 付記１に記載の業務プロセストラッキング装置において，
前記出力手段は，前記出力された業務データのツリー上で選択された業務データに関連するイベントを，前記業務プロセス定義情報に基づいて作成される業務プロセスの図上に表示する手段を備える
ことを特徴とする業務プロセストラッキング装置。

（付記３） 付記２に記載の業務プロセストラッキング装置において，
前記業務プロセス定義情報として，イベントとしての各業務データの標準処理時間の定義情報を持ち，
前記出力手段は，前記イベントの表示の際に，標準処理時間に対する遅れ度またはそのイベントの処理が完了するまでの予測時間を算出し表示する
ことを特徴とする業務プロセストラッキング装置。

（付記４） 付記１，付記２または付記３に記載の業務プロセストラッキング装置において，
前記各業務システムは，前記業務プロセス定義情報に基づき，各業務システムにおいて抽出すべきイベント情報を定義したイベント抽出定義情報の記憶手段と，
あらかじめ定義されたイベント抽出定義情報に基づきイベントデータを抽出するイベント抽出手段とを備える
ことを特徴とする業務プロセストラッキング装置。

（付記５） 付記１から付記４までのいずれかに記載の業務プロセストラッキング装置において，
前記各業務システムは，前記イベント抽出手段が抽出したイベントデータを，各業務システムに共通のマークアップ言語で表現されるデータに変換するイベントデータ変換手段を備える
ことを特徴とする業務プロセストラッキング装置。

（付記６） 異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング方法であって，
各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶するステップと，
前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集するステップと，
前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行うステップと，
前記関連付けられた業務データをイベント管理データ記憶手段に蓄積するステップと，
入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力するステップとを有する
ことを特徴とする業務プロセストラッキング方法。

（付記７） 異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング方法をコンピュータに実行させるためのプログラムであって，
各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶する処理と，
前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集する処理と，
前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行う処理と，
前記関連付けられた業務データをイベント管理データ記憶手段に蓄積する処理と，
入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力する処理とを，
コンピュータに実行させるための業務プロセストラッキングプログラム。

（付記８） 異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング方法をコンピュータに実行させるためのプログラムを記録した記録媒体であって，
各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶する処理と，
前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集する処理と，
前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行う処理と，
前記関連付けられた業務データをイベント管理データ記憶手段に蓄積する処理と，
入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力する処理とを，
コンピュータに実行させるための業務プロセストラッキングプログラムを記録した記録媒体。

本発明のシステム構成例を示す図である。 業務システムの配置例を示す図である。 業務プロセスＤＢ内に格納する定義データの入力画面を示す図である。 業務プロセスＤＢ内に格納する定義データの入力画面を示す図である。 業務プロセスＤＢ内に格納する定義データのデータ構成を示す図である。 業務プロセスＤＢ内に格納する定義データのデータ構成を示す図である。 イベント抽出定義画面の一例を示す図である。 イベント抽出定義画面の一例を示す図である。 イベント抽出定義の一例を示す図である。 イベント抽出定義の配置例を示す図である。 イベントデータの一例を示す図である。 業務データの関連付けの結果を示す図である。 フロー表示用ＳＶＧファイルの例を示す図である。 イベント管理装置における処理フローの概要を示す図である。 業務データの関連付け処理フローを示す図である。 イベントデータまたは発注伝票，受注伝票を示す図である。 業務データの関連付け処理を説明する模式図である。 業務データの関連付けを示す図である。 業務データ（伝票）の作成処理の例を示す図である。 業務データ（伝票）の作成処理の例を示す図である。 業務データ（伝票）の作成処理の例を示す図である。 複数の業務システムからのイベント収集の流れを説明する図である。 複数の業務システムからのイベント収集の流れを説明する図である。 複数の業務システムからのイベント収集の流れを説明する図である。 複数の業務システムからのイベント収集の流れを説明する図である。 複数の業務システムからのイベント収集の流れを説明する図である。 複数の業務システムからのイベント収集の流れを説明する図である。 業務データの検索条件入力画面の例を示す図である。 業務データの検索条件入力画面の例を示す図である。 検索結果の表示例を示す図である。 業務プロセスのトラッキング過程における操作と表示の一例を示す図である。 業務プロセスの逆トラッキング過程における操作と表示の一例を示す図である。 業務プロセスのトラッキング結果画面の例を示す図である。 イベントエクスプローラの表示処理フローを示す図である。 業務プロセスのトラッキング表示処理フローを示す図である。 アラート表示画面の例を示す図である。 従来の一般的なワークフローシステムの概要を示す図である。 従来の一般的なワークフローシステムの一例を示す図である。

符号の説明

１ イベント管理装置
３〜５ 業務システムＡ〜Ｃ
６ ユーザ端末
１１ 入力部
１２ イベントキュー
１３ イベント関連付け部
１４ イベント管理ＤＢ
１５ 業務プロセスＤＢ
１６ 出力部
２０ フロー管理サーバ
２１〜２４ アプリケーションＥ〜Ｈ
３０ アプリケーションＡ
３１，３１’４１，４１’，５１，５１’，２１０，２２０，２３０，２４０ 状態ＤＢ
３２，４２，５２ イベント抽出部
３３，４３，５３ イベントデータ変換部
３４，４４，５４ イベントデータ送信部
４０ アプリケーションＢ
５０ アプリケーションＣ
２００〜２０２ ワークフローＥ〜Ｇ
２０３ 履歴ＤＢ
３２０，４２０，５２０ イベント抽出定義
３２０−１ 受注抽出定義
３２０−２ 在庫照会抽出定義
４２０−１ 発注抽出定義
４２０−２ 受入抽出定義
５２０−１ 出荷抽出定義
５２０−２ 配送抽出定義

Claims (4)

1. 異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング装置であって，
   各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶する手段と，
   前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集するイベントデータ収集手段と，
   前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行うイベント関連付け手段と，
   前記関連付けられた業務データを蓄積するイベント管理データ記憶手段と，
   入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力する出力手段とを備え，
   前記イベント関連付け手段は，一の業務データの関連付け対象となる業務データが存在しないときには，該関連付け対象となる業務データを作成したうえで該一の業務データとの関連付けを行い，
   前記出力手段は，前記出力された業務データのツリー上で選択された業務データに関連するイベントを，前記業務プロセス定義情報に基づいて作成される業務プロセスの図上に表示する
   ことを特徴とする業務プロセストラッキング装置。
2. 業務プロセストラッキング装置によって実行される，異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング方法であって，
   前記業務プロセストラッキング装置が，
   各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶するステップと，
   前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集するステップと，
   前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行うステップと，
   前記関連付けられた業務データをイベント管理データ記憶手段に蓄積するステップと，
   入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力するステップとを実行し，
   前記関連付けを行うステップでは，一の業務データの関連付け対象となる業務データが存在しないときには，該関連付け対象となる業務データを作成したうえで該一の業務データとの関連付けを行い，
   前記出力するステップでは，さらに前記出力された業務データのツリー上で選択された業務データに関連するイベントを，前記業務プロセス定義情報に基づいて作成される業務プロセスの図上に表示する
   ことを特徴とする業務プロセストラッキング方法。
3. 異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング方法をコンピュータに実行させるためのプログラムであって，
   各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶する処理と，
   前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集する処理と，
   前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行う処理と，
   前記関連付けられた業務データをイベント管理データ記憶手段に蓄積する処理と，
   入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力する処理とを，コンピュータに実行させ，
   前記関連付けを行う処理において一の業務データの関連付け対象となる業務データが存在しないときには，該関連付け対象となる業務データを作成したうえで該一の業務データとの関連付けを行う処理と，
   前記出力する処理において，さらに前記出力された業務データのツリー上で選択された業務データに関連するイベントを，前記業務プロセス定義情報に基づいて作成される業務プロセスの図上に表示する処理とを，
   コンピュータに実行させるための業務プロセストラッキングプログラム。
4. 異なる業務システム間を跨がって実行される業務の流れである業務プロセスを追跡する業務プロセストラッキング方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって，
   各業務システム内の業務で扱う業務データと，各業務データ間の関連情報を定義した業務プロセス定義情報を記憶する処理と，
   前記業務システム内において抽出された各業務を実行するアプリケーションの実行状態を示す情報であるイベントデータを収集する処理と，
   前記収集されたイベントデータを前記業務プロセス定義情報に基づき業務データ単位でまとめ，イベントデータとして取得した業務データ間の関連付けを行う処理と，
   前記関連付けられた業務データをイベント管理データ記憶手段に蓄積する処理と，
   入力された検索条件に基づいて前記イベント管理データ記憶手段を検索し，業務データ間の関連をツリー形式で出力する処理とを，コンピュータに実行させ，
   前記関連付けを行う処理において一の業務データの関連付け対象となる業務データが存在しないときには，該関連付け対象となる業務データを作成したうえで該一の業務データとの関連付けを行う処理と，
   前記出力する処理においてさらに前記出力された業務データのツリー上で選択された業務データに関連するイベントを，前記業務プロセス定義情報に基づいて作成される業務プロセスの図上に表示する処理とを，
   コンピュータに実行させるための業務プロセストラッキングプログラムを記録した記録媒体。

Images