(57)【要約】【課題】業務プロセストラッキングの簡単かつ効率的なバージョン管理を図ること。【解決手段】業務プロセストラッキング装置１０２では、管理端末受付部６０１により、管理端末１０３からのログインがあった場合、更新する業務モデルとそのバージョンを待ち受ける。登録部６０２により、受け付けられたバージョンに従って、モデル版数管理テーブル５００を更新する。トラッキング端末受付部６０５により、トラッキング端末１０４からログイン、トラッキングする業務モデルとそのバージョン番号が受け付けられた場合、特定部６０６により、モデル版数管理テーブル５００から、受け付けられたバージョン番号の業務モデルに関する運用時間情報を特定する。トラッキング処理部６０７により、取得された運用時間情報に従ってトラッキング処理を実行し、トラッキング結果をトラッキング端末１０４に出力する。【選択図】        図６
2006293548.tif 000002
【特許請求の範囲】
【請求項１】
複数の業務システム間の業務の流れを示す業務プロセスを追跡させる業務プロセストラッキングプログラムにおいて、
前記複数の業務システムによって定義される業務モデルにおける、現在運用中のバージョンから更新された更新後のバージョンの登録を受け付ける登録受付手段、
前記登録受付手段によって更新後のバージョンの登録が受け付けられた場合、前記現在運用中のバージョンの運用終了および前記更新後のバージョンの運用開始に関する時間情報を登録する登録手段、
としてコンピュータを機能させることを特徴とする業務プロセストラッキングプログラム。
【請求項２】
前記登録受付手段は、
前記業務モデルにおける非運用のバージョンから更新された更新後のバージョンの登録を受け付け、
前記登録手段は、
前記登録受付手段によって更新後のバージョンの登録が受け付けられた場合、前記非運用のバージョンの運用開始および運用終了に関する時間情報を更新後のバージョンの時間情報として登録することを特徴とする請求項１に記載の業務プロセストラッキングプログラム。
【請求項３】
前記業務モデルのトラッキング対象となるバージョンを受け付けるトラッキング受付手段、
前記登録手段によって登録された時間情報の中から、前記トラッキング受付手段によって受け付けられたバージョンに合致するバージョンの時間情報を特定する特定手段と、
前記特定手段によって特定された時間情報に基づいて、前記業務プロセスの追跡を実行する実行手段、
としてコンピュータを機能させることを特徴とする請求項１または２に記載の業務プロセストラッキングプログラム。
【請求項４】
請求項１〜３のいずれか一つに記載の業務プロセストラッキングプログラムを記録したコンピュータに読み取り可能な記録媒体。
【請求項５】
複数の業務システム間の業務の流れを示す業務プロセスを追跡する業務プロセストラッキング装置において、
前記複数の業務システムによって定義される業務モデルにおける、現在運用中のバージョンから更新された更新後のバージョンの登録を受け付ける登録受付手段と、
前記登録受付手段によって更新後のバージョンの登録が受け付けられた場合、前記現在運用中のバージョンの運用終了および前記更新後のバージョンの運用開始に関する時間情報を登録する登録手段と、
を備えることを特徴とする業務プロセストラッキング装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数の業務システム間の業務の流れを示す業務プロセスを追跡する業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置に関する。
【背景技術】
【０００２】
企業の成長に伴う業務システムの段階的導入や、ビジネスユニット単位での個別業務システムの導入により、企業内に複数の業務システムが存在するケースが多くなっている。これらの業務システムが複雑に関係し合うため、『業務全体の進捗を把握しにくい』、『業務プロセスの問題点がわからない』、『新規のＩＴ投資をどこに行うとどのような効果があるかわからない』といった問題が生じている。
【０００３】
このように、稼働中の既存業務の改善をおこなう場合、どの部分に問題があり、どこを改善したらよいかを判断するために業務システム間の業務の流れを示す業務プロセスの分析が従来からおこなわれている。このため、業務システム間の業務がどのように流れているかを見るシステムとしてワークフローシステムがある。ワークフローシステムとは、一般に、既存のフローエンジンと、提示されたワークフローに従った順序で自動実行するアプリケーションとを備えるシステムである。
【０００４】
また、異なる業務システムにまたがるようなワークフローや非定型業務についても、その履歴や進行状態の管理情報を参照したり、辿ったりすることを可能にするワークフロー支援システムおよび支援方法が開示されている（たとえば、下記特許文献１を参照。）。
【０００５】
【特許文献１】特開平１０−６３７４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述した従来技術では、途中で複数に分岐するアプリケーションの関係を把握することができないという問題があった。また、途中で複数に分岐するアプリケーションの関係を把握するためには、複数のプロセスに分割して別々に分析するなど、業務プロセスと分析方法の見直しが必要であった。
【０００７】
また、既存の多くの業務システムは、ワークフローにしたがって業務処理を追行しているわけではない。このため、異なる業務システム間の業務の流れを追跡する場合には、個々の業務システムにアクセスして処理済データ、未処理データなどのデータを収集し、分析しなければならず、業務の流れの追跡は現実には不可能であった。
【０００８】
この発明は、上述した従来技術による問題点を解消するため、複数の業務システム間の業務の流れを示す業務プロセスのトラッキングを、簡単かつ効率的なバージョン管理を図ることができる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するため、この発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置は、複数の業務システム間の業務の流れを示す業務プロセスを追跡させる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置において、前記複数の業務システムによって定義される業務モデルにおける、現在運用中のバージョンから更新された更新後のバージョンの登録を受け付け、更新後のバージョンの登録が受け付けられた場合、前記現在運用中のバージョンの運用終了および前記更新後のバージョンの運用開始に関する時間情報を登録することを特徴とする。
【００１０】
また、上記発明において、前記業務モデルにおける非運用のバージョンから更新された更新後のバージョンの登録を受け付け、更新後のバージョンの登録が受け付けられた場合、前記非運用のバージョンの運用開始および運用終了に関する時間情報を更新後のバージョンの時間情報として登録することとしてもよい。
【００１１】
また、上記発明において、前記業務モデルのトラッキング対象となるバージョンを受け付け、登録された時間情報の中から、受け付けられたバージョンに合致するバージョンの時間情報を特定し、特定された時間情報に基づいて、前記業務プロセスの追跡を実行することとしてもよい。
【００１２】
これらの発明によれば、現在運用中のバージョンの運用開始および運用終了の時間情報を登録することにより、非運用のバージョンの業務モデルとすることができるとともに、更新後のバージョンをあらたに現在運用中のバージョンの業務モデルとして登録することができる。また、非運用のバージョンの運用開始および運用終了の時間情報を用いて、更新後の非運用のバージョンを登録することができる。また、業務プロセスのトラッキングを、指定されたバージョンの業務モデルに特定しておこなうことができる。
【発明の効果】
【００１３】
本発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置によれば、簡単かつ効率的なバージョン管理を図ることができるという効果を奏する。
【発明を実施するための最良の形態】
【００１４】
以下に添付図面を参照して、この発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置の好適な実施の形態を詳細に説明する。なお、本実施の形態では、異なる業務間の繋がりや流れは、ビジネスプロセスの見直しにより常に変化するため、異なる業務システム間の流れを蓄積・追跡するだけではなく、異なる業務間の繋がりの変化と蓄積した情報を比較し、トラッキング範囲の判別をすることができる。
【００１５】
（業務プロセストラッキングシステムのシステム構成）
まず、この発明の実施の形態にかかる業務プロセストラッキングシステムのシステム構成について説明する。図１は、この発明の実施の形態にかかる業務プロセストラッキングシステムのシステム構成図である。
【００１６】
図１において、業務プロセストラッキングシステム１００は、内部システム１０１と、業務システム群ＷＳと、バックアップサーバ１１０とが、インターネットやＷＡＮなどのネットワーク１２０を介して相互に交信可能に接続されている。
【００１７】
内部システム１０１は、業務プロセストラッキング装置１０２と、管理端末１０３と、トラッキング端末１０４が相互に交信可能に接続されており、ＬＡＮなどの内部ネットワークを構成している。また、業務プロセストラッキング装置１０２は、業務プロセスの追跡、監視、および管理をおこなう。管理端末１０３は、業務プロセストラッキング装置１０２の起動動作または終了動作の指示、追跡、監視、および管理に関する処理のスケジュール設定などをおこなう。トラッキング端末１０４は、業務プロセストラッキング装置１０２にアクセスして、目的とする業務プロセスの追跡要求、追跡対象の指定および追跡結果の表示をおこなう。
【００１８】
また、業務システム群ＷＳは、ある業務モデルにしたがって定義された複数（ｎ個）の異なる業務システムＷＳ１〜ＷＳｎの集合である。個々の業務システムＷＳｉは、他の業務システムＷＳｊ（ｊ≠ｉ）の作業状況を把握していない。ここで、業務システム群ＷＳの業務システム数ＷＳ１〜ＷＳｎのｎをｎ＝４として簡単に説明すると、たとえば、商品の受注から出荷まで手がける業務モデルである場合、受注システム（業務システムＷＳ１）、調達システム（業務システムＷＳ２）、組立システム（業務システムＷＳ３）、および出荷システム（業務システムＷＳ４）の４つの業務システムによって構成することができる。ここで、業務プロセスとは、業務システムＷＳ１〜ＷＳｎ間の業務の流れを示しているため、この場合の業務プロセスとは、たとえば、ある商品の受注処理から、調達管理処理、組立処理、出荷処理までの一連の処理である。
【００１９】
実際には、業務システムＷＳ１〜ＷＳｎの数ｎは、数十個〜百個以上有するものもあり、追跡対象となる業務プロセスも大規模化、多様化している。本実施の形態では、このように大規模化、多様化した業務プロセスについても、追跡、監視および管理の効率化を図ることができる。また、バックアップサーバ１１０は、業務プロセストラッキング装置１０２に記憶されている情報をバックアップする。
【００２０】
（業務プロセストラッキング装置１０２等のハードウェア構成）
まず、この発明の実施の形態にかかる業務プロセストラッキング装置１０２、管理端末１０３、トラッキング端末１０４、バックアップサーバ１１０、各業務システムＷＳ１〜ＷＳｎ（以下、「業務プロセストラッキング装置１０２等」という）のハードウェア構成について説明する。図２は、この発明の実施の形態にかかる業務プロセストラッキング装置１０２等のハードウェア構成を示すブロック図である。
【００２１】
図２において、業務プロセストラッキング装置１０２等は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、ＨＤＤ（ハードディスクドライブ）２０４と、ＨＤ（ハードディスク）２０５と、ＦＤＤ（フレキシブルディスクドライブ）２０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）２０７と、ディスプレイ２０８と、Ｉ／Ｆ（インターフェース）２０９と、キーボード２１０と、マウス２１１と、スキャナ２１２と、プリンタ２１３と、を備えている。また、各構成部はバス２００によってそれぞれ接続されている。
【００２２】
ここで、ＣＰＵ２０１は、業務プロセストラッキング装置１０２等の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。ＨＤＤ２０４は、ＣＰＵ２０１の制御にしたがってＨＤ２０５に対するデータのリード／ライトを制御する。ＨＤ２０５は、ＨＤＤ２０４の制御で書き込まれたデータを記憶する。
【００２３】
ＦＤＤ２０６は、ＣＰＵ２０１の制御にしたがってＦＤ２０７に対するデータのリード／ライトを制御する。ＦＤ２０７は、ＦＤＤ２０６の制御で書き込まれたデータを記憶したり、ＦＤ２０７に記憶されたデータを業務プロセストラッキング装置１０２等に読み取らせたりする。
【００２４】
また、着脱可能な記録媒体として、ＦＤ２０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ２０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ２０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
【００２５】
Ｉ／Ｆ２０９は、通信回線を通じてインターネットなどのネットワーク１２０に接続され、このネットワーク１２０を介して他の装置に接続される。そして、Ｉ／Ｆ２０９は、ネットワーク１２０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。
【００２６】
キーボード２１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス２１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
【００２７】
スキャナ２１２は、画像を光学的に読み取り、業務プロセストラッキング装置１０２等内に画像データを取り込む。なお、スキャナ２１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ２１３は、画像データや文書データを印刷する。プリンタ２１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。
【００２８】
（業務モデルのバージョン変化推移）
つぎに、この発明の実施の形態にかかる業務モデルのバージョン変化推移について説明する。図３は、この発明の実施の形態にかかる業務モデルのバージョン変化推移を示す説明図である。本実施の形態で管理される業務モデルのバーション（版数）は２種類規定されている。
【００２９】
一つは、『メジャーバージョン』と呼ばれ、業務モデル内で登録された定義ファイルを区別する単位を示している。異なるメジャーバージョンどうしはそれぞれ影響を与えない。このメジャーバージョンの中で値が最も大きいメジャーバージョンが、業務モデル内でのアクティブモデルとして認識される。たとえば、業務システムの追加、削除、変更、置換、業務システムの順番の入れ替えなど、業務の流れ（業務プロセス）に影響がある変更の場合、メジャーバージョンのバージョンアップが行われる。
【００３０】
もう一つは、『マイナーバージョン』と呼ばれ、上述したメジャーバージョン内で区別するバージョンである。あるメジャーバージョンの業務モデル内でプロセスの置き換えが発生すると、マイナーバージョンの値が加えられ、管理テーブルに保管される。このマイナーバージョンの中で値が最も大きいマイナーバージョンの値の業務モデルが、そのメジャーバージョン内の業務モデルとして利用される。たとえば、業務モデル内の業務システムの名称変更、業務システムのプロパティの変更など、業務の流れ（業務プロセス）に影響がない変更の場合、マイナーバージョンのバージョンアップが行われる。
【００３１】
なお、以下において、業務モデルのバージョン番号を、メジャーバージョンおよびそのマイナーバージョンからなる『ＶｘＬｙ』によって表記する。「Ｖ」はメジャーバージョンをあらわしており、「ｘ」はメジャーバージョンＶの値（バージョン番号）をあらわしている。同様に、「Ｌ」はマイナーバージョンをあらわしており、「ｙ」はマイナーバージョンＬの値（バージョン番号）をあらわしている。たとえば、「Ｖ１Ｌ０」は、メジャーバージョン１でマイナーバージョン０の業務モデルをあらわしている。
【００３２】
図３において、定義ファイル３０１はメジャーバージョンのバージョン番号がＶ１であるＶ１系モデルを示しており、定義ファイル３０２はメジャーバージョンのバージョン番
号がＶ２であるＶ２系モデルを示しており、定義ファイル３０３はメジャーバージョンの
バージョン番号がＶ３であるＶ３系モデルを示している。なお、枠３０４内の業務モデル
は、アクティブモデルである。アクティブモデルとは、現在運用されている業務システム群ＷＳを定義する最新バージョンの業務モデルであり、トラッキング端末１０４からのトラッキング対象となるイベントデータを生成する業務モデルである。
【００３３】
また、ここでは、業務モデルとして、上述した商品の受注から出荷まで手がける受注・出荷業務モデルを例に挙げて説明する。受注・出荷業務モデルは、導入当初であるバージョン：Ｖ１Ｌ０においては、受注システムＷＳ１、調達システムＷＳ２、組立システムＷＳ３、および出荷システムＷＳ４から構成されている。
【００３４】
まず、受注・出荷業務モデル（バージョン：Ｖ１Ｌ０）がアクティブモデルであるときに、たとえばいずれかのシステムＷＳ１〜ＷＳ４の名称変更が発生した場合、マイナーバージョンのバージョンアップが行われ、バージョン番号が『Ｖ１Ｌ０』から『Ｖ１Ｌ１』に更新される。これにより、受注・出荷業務モデル（バージョン：Ｖ１Ｌ１）がアクティブモデルとなる。
【００３５】
このあと、あらたな業務システムが追加された場合、メジャーバージョンのバージョンアップが行われ、Ｖ２系モデルをあらわす定義ファイル３０２を登録することにより、バ
ージョン番号が『Ｖ１Ｌ１』から『Ｖ２Ｌ０』に更新される。これにより、受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）がアクティブモデルとなる。
【００３６】
なお、Ｖ１系モデルである受注・出荷業務モデル（バージョン：Ｖ１Ｌ０、Ｖ１Ｌ１）は、期間ｔ１〜ｔ２においてアクティブモデルであり、ｔ２以降は非アクティブモデルとなる。管理上は、期間ｔ１〜ｔ２における受注・出荷業務モデル（バージョン：Ｖ１Ｌ０、Ｖ１Ｌ１）のイベントデータは保管されているため、トラッキング端末１０４からバージョン番号や期間を指定することにより、イベントデータのトラッキング（追跡）をおこなうことができる。
【００３７】
また、受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）がアクティブモデルであるときに、あらたな業務システムが追加された場合、メジャーバージョンのバージョンアップが行われ、Ｖ３系モデルをあらわす定義ファイル３０３を登録することにより、バージョン
番号が『Ｖ２Ｌ０』から『Ｖ３Ｌ０』に更新される。これにより、受注・出荷業務モデル（バージョン：Ｖ３Ｌ０）がアクティブモデルとなる。
【００３８】
なお、Ｖ２系モデルである受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）は、期間ｔ２〜ｔ３においてアクティブモデルであり、ｔ３以降は非アクティブモデルとなる。管理上は、期間ｔ２〜ｔ３における受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）のイベントデータは保管されているため、トラッキング端末からバージョン番号や期間を指定することにより、イベントデータのトラッキング（追跡）をおこなうことができる。
【００３９】
また、受注・出荷業務モデル（バージョン：Ｖ３Ｌ０）がアクティブモデルであるときに、旧バージョンである非アクティブモデルのマイナーバージョンアップも行うことができる。たとえば、受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）内の業務システムをマイナーバージョンアップして、受注・出荷業務モデル（バージョン：Ｖ２Ｌ１）にすることができる。これにより、このバージョンアップ以降は、管理上、受注・出荷業務モデル（バージョン：Ｖ２Ｌ１）が、Ｖ２系モデルのトラッキング対象の業務モデルとなる。
【００４０】
つぎに、図３に示した各バージョンでの業務プロセスについて説明する。図４−１〜図４−５は、図３に示した各バージョンでの業務プロセスを示す説明図である。図４−１は、受注・出荷業務モデル（バージョン：Ｖ１Ｌ０）の業務プロセスを示しており、その業務プロセスは、受注システムＷＳ１（ステップＳ１０１）、調達システムＷＳ２（ステップＳ１０２）、組立システムＷＳ３（ステップＳ１０３）、および出荷システムＷＳ４（ステップＳ１０４）の順に実行される。
【００４１】
また、図４−２は、受注・出荷業務モデル（バージョン：Ｖ１Ｌ１）の業務プロセスである。受注・出荷業務モデル（バージョン：Ｖ１Ｌ１）は、図４−１に示した受注・出荷業務モデル（バージョン：Ｖ１Ｌ０）の業務プロセスからのマイナーバージョンアップ（図４−１のステップＳ１０３に示した組立システムＷＳ３から生産システムＷＳ３への名称変更）を示しており、その業務プロセスは、受注システムＷＳ１（ステップＳ１１１）、調達システムＷＳ２（ステップＳ１１２）、生産システムＷＳ３（ステップＳ１１３）、および出荷システムＷＳ４（ステップＳ１１４）の順に実行される。
【００４２】
また、図４−３は、受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）の業務プロセスである。受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）は、図４−２に示した受注・出荷業務モデル（バージョン：Ｖ１Ｌ１）の業務プロセスからのメジャーバージョンアップ（在庫管理システムＷＳ５および検査システムＷＳ６の追加）を示しており、その業務プロセスは、受注システムＷＳ１（ステップＳ２０１）、在庫管理システムＷＳ５（ステップＳ２０２）、調達システムＷＳ２（ステップＳ２０３）、生産システムＷＳ３（ステップＳ２０４）、検査システムＷＳ６（ステップＳ２０５）、および出荷システムＷＳ４（ステップＳ２０６）の順に実行される。なお、調達システムＷＳ２（ステップＳ２０３）は、在庫管理システムＷＳ５（ステップＳ２０２）において在庫不足である場合に実行され、在庫が充足している場合には、生産システムＷＳ３（ステップＳ２０４）を実行する。
【００４３】
また、図４−４は、受注・出荷業務モデル（バージョン：Ｖ３Ｌ０）の業務プロセスである。受注・出荷業務モデル（バージョン：Ｖ３Ｌ０）は、図４−３に示した受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）の業務プロセスからのメジャーバージョンアップ（決済システムＷＳ７の追加）を示しており、その業務プロセスは、受注システムＷＳ１（ステップＳ３０１）、在庫管理システムＷＳ５（ステップＳ３０２）、調達システムＷＳ２（ステップＳ３０３）、生産システムＷＳ３（ステップＳ３０４）、検査システムＷＳ６（ステップＳ３０５）、出荷システムＷＳ４（ステップＳ３０６）、および決済システムＷＳ７（ステップＳ３０７）の順に実行される。なお、調達システムＷＳ２（ステップＳ３０３）は、在庫管理システムＷＳ５（ステップＳ３０２）において在庫不足である場合に実行され、在庫が充足している場合には、生産システムＷＳ３（ステップＳ３０４）を実行する。
【００４４】
また、図４−５は、受注・出荷業務モデル（バージョン：Ｖ２Ｌ１）の業務プロセスである。受注・出荷業務モデル（バージョン：Ｖ２Ｌ１）は、図４−３に示した受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）の業務プロセスからのマイナーバージョンアップ（図４−３のステップＳ２０５に示した検査システムＷＳ６から承認システムＷＳ６への名称変更）を示しており、その業務プロセスは、受注システムＷＳ１（ステップＳ２１１）、在庫管理システムＷＳ５（ステップＳ２１２）、調達システムＷＳ２（ステップＳ２１３）、生産システムＷＳ３（ステップＳ２１４）、承認システムＷＳ６（ステップＳ２１５）、および出荷システムＷＳ４（ステップＳ２１６）の順に実行される。なお、調達システムＷＳ２（ステップＳ２１３）は、在庫管理システムＷＳ５（ステップＳ２１２）において在庫不足である場合に実行され、在庫が充足している場合には、生産システムＷＳ３（ステップＳ２１４）を実行する。
【００４５】
（モデル版数管理テーブルの記憶内容）
つぎに、この発明の実施の形態にかかるモデル版数管理テーブルの記憶内容について説明する。図５は、この発明の実施の形態にかかるモデル版数管理テーブルの記憶内容を示す図表である。図５において、モデル版数管理テーブル５００には、各業務モデルのバージョンＶｘＬｙと、運用時間情報とが記憶されている。運用時間情報とは、当該バージョンの運用開始日時と運用終了日時を有している。
【００４６】
運用開始日時は、バージョンアップ直前のバージョンの運用終了日時と一致する。なお、バージョン番号：Ｖ１Ｌ０の場合、運用開始日時は、業務モデルの導入日時である。また、非アクティブモデルのないマイナーバージョンアップがあった場合、たとえば、バージョン：Ｖ２Ｌ１に関しては、すでに、メジャーバージョンアップされたＶ３系モデルが
アクティブモデルとなっているため、運用開始日時および運用終了日時ともに、バージョン番号：Ｖ２Ｌ０と同一日時となる。
【００４７】
（業務プロセストラッキング装置１０２の機能的構成）
つぎに、この発明の実施の形態にかかる業務プロセストラッキング装置１０２の機能的構成について説明する。図６は、この発明の実施の形態にかかる業務プロセストラッキング装置１０２の機能的構成を示すブロック図である。図６において、業務プロセストラッキング装置１０２は、モデル版数管理テーブル５００と、管理端末受付部６０１と、登録部６０２と、イベントデータ収集部６０３と、イベントＤＢ（データベース）６０４と、トラッキング端末受付部６０５と、特定部６０６と、トラッキング処理部６０７と、出力部６０８と、から構成されている。
【００４８】
まず、管理端末受付部６０１は、管理端末１０３からの情報を受け付ける。具体的には、管理端末１０３からのログインや、登録対象となる業務モデルおよびそのバージョンＶｘＬｙを受け付ける。
【００４９】
登録部６０２は、管理端末受付部６０１によって受け付けられたバージョン情報に従って、モデル版数管理テーブル５００を更新する。具体的には、業務モデル名およびバージョン情報を、モデル版数管理テーブル５００に登録する。そして、さらに、運用時間情報を登録する。たとえば、バージョン番号Ｖ１Ｌ０からマイナーバージョンアップによるバージョン情報の登録が受け付けられた場合、あらたなＩＤ：２に、バージョン番号：Ｖ１Ｌ１を登録するとともに、運用開始日時に現在の日時を登録する。なお、この場合、直前バージョンであるバージョン番号：Ｖ１Ｌ０の運用終了日時にも、現在の日時を登録する。
【００５０】
また、イベントデータ収集部６０３は、あらかじめ設定されたスケジュールにしたがって、アクティブモデルである業務システムにより構成される業務システム群ＷＳから、イベントデータを収集する。たとえば、受注・出荷業務モデル（バージョン：Ｖ２Ｌ０）がアクティブモデルである場合、図４−３に示したように、業務プロセスとして、受注システムＷＳ１（ステップＳ２０１）、在庫管理システムＷＳ５（ステップＳ２０２）、調達システムＷＳ２（ステップＳ２０３）、生産システムＷＳ３（ステップＳ２０４）、検査システムＷＳ６（ステップＳ２０５）、および出荷システムＷＳ４（ステップＳ２０６）の順に実行されている。
【００５１】
したがって、イベントデータ収集部６０３は、受注システムＷＳ１、在庫管理システムＷＳ５、調達システムＷＳ２、生産システムＷＳ３、検査システムＷＳ６、および出荷システムＷＳ４から、それぞれイベントデータを収集する。なお、イベントデータ収集部６０３は、収集したイベントデータを、イベントＤＢ６０４に格納する。
【００５２】
また、イベントＤＢ６０４は、イベントデータ収集部６０３によって収集されたイベントデータを記憶する。ここで、イベントＤＢ６０４の記憶内容の一例について説明する。図７は、イベントＤＢ６０４の記憶内容の一例を示す説明図である。図７において、イベントＤＢ６０４は、業務システム名、実行開始日時および実行終了日時を含むイベントデータを、業務システムごとに記憶している。
【００５３】
また図６において、トラッキング端末受付部６０５は、トラッキング端末１０４からのログイン、トラッキング指示、トラッキング対象となる業務モデルおよびバージョン番号の指示を受け付ける。特定部６０６は、トラッキング端末受付部６０５によって受け付けられた業務モデルおよびそのバージョン番号に基づいて、モデル版数管理テーブル５００を参照し、運用時間情報を特定する。
【００５４】
たとえば、トラッキング端末１０４から、受注・出荷業務モデル（バージョン：Ｖ１Ｌ０）についてトラッキング指示が受け付けられた場合、モデル版数管理テーブル５００から受注・出荷業務モデル（バージョン：Ｖ１Ｌ０）の運用開始日時『２００３／０１／０１，００：００』および運用終了日時『２００３／０９／０１，０４：００』を特定する。
【００５５】
また、アクティブモデルである受注・出荷業務モデル（バージョン：Ｖ３Ｌ０）についてトラッキング指示が受け付けられた場合、モデル版数管理テーブル５００から出荷業務モデル（バージョン：Ｖ３Ｌ０）の運用開始日時『２００４／０６／０３，００：００』を特定する。受注・出荷業務モデル（バージョン：Ｖ３Ｌ０）は、アクティブモデルであるため、運用終了日時は特定されず、運用開始日時から現在日時までがトラッキング対象期間となる。
【００５６】
また、トラッキング処理部６０７は、特定部６０６によって特定された運用時間情報に従って、イベントＤＢ６０４に記憶されているイベントデータを検索することで、業務プロセスを追跡（トラッキング）する。たとえば、特定部６０６により、受注・出荷業務モデル（バージョン：Ｖ１Ｌ０）の運用開始日時『２００４／０１／０１，００：００』および運用終了日時『２００４／０９／０１，０４：００』が特定された場合、この運用開始日時から運用終了日時の間に実行されたイベントデータ、すなわち、図７のＩＤ１〜ＩＤ４までのイベントデータを検索する。
【００５７】
また、出力部６０８は、トラッキング処理部６０７によって検索されたイベントデータをトラッキング結果として、トラッキング指示を要求したトラッキング端末１０４に出力する。なお、上述した管理端末受付部６０１、登録部６０２と、イベントデータ収集部６０３、トラッキング端末受付部６０５、特定部６０６、トラッキング処理部６０７、および出力部６０８は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ＨＤ２０５などの記録媒体に記録されたプログラムを、ＣＰＵ２０１が実行することによって、またはＩ／Ｆ２０９によって、その機能を実現する。また、モデル版数管理テーブル５００およびイベントＤＢ６０４（データベース）は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ＨＤ２０５などの記録媒体によって、その機能を実現する。
【００５８】
（モデル版数管理テーブル５００の更新処理手順）
つぎに、この発明の実施の形態にかかるモデル版数管理テーブル５００の更新処理手順について説明する。図８は、この発明の実施の形態にかかるモデル版数管理テーブル５００の更新処理手順を示すフローチャートである。まず、管理端末受付部６０１により、管理端末１０３からのログインを待ち受け（ステップＳ８０１：Ｎｏ）、ログインがあった場合（ステップＳ８０１：Ｙｅｓ）、更新された業務モデルのバージョン情報の登録を待ち受ける（ステップＳ８０２：Ｎｏ）。更新された業務モデルのバージョン情報の登録が受け付けられた場合（ステップＳ８０２：Ｙｅｓ）、登録部６０２により、受け付けられたバージョン情報をモデル版数管理テーブル５００に登録することにより、モデル版数管理テーブル５００を更新する（ステップＳ８０３）。これにより、一連の更新処理を終了する。
【００５９】
（業務プロセストラッキング処理手順）
つぎに、この発明の実施の形態にかかる業務プロセストラッキング処理手順について説明する。図９は、この発明の実施の形態にかかる業務プロセストラッキング処理手順を示すフローチャートである。まず、トラッキング端末受付部６０５により、トラッキング端末１０４からログインを待ち受け（ステップＳ９０１：Ｎｏ）、ログインがあった場合（ステップＳ９０１：Ｙｅｓ）、トラッキングする業務モデルとそのバージョン番号を待ち受ける（ステップＳ９０２：Ｎｏ）。
【００６０】
トラッキングする業務モデルとそのバージョン番号が受け付けられた場合（ステップＳ９０２：Ｙｅｓ）、特定部６０６により、モデル版数管理テーブル５００から、受け付けられたバージョン番号の業務モデルに関する運用時間情報を特定する（ステップＳ９０３）。そして、トラッキング処理部６０７により、取得された運用時間情報に従って、トラッキング処理を実行し（ステップＳ９０４）、このトラッキング処理によって得られたトラッキング結果を、出力部６０８により、トラッキング端末１０４に出力する（ステップＳ９０５）。これにより一連の処理を終了する。
【００６１】
単なるトラッキングシステムにおいて、個々の業務システムでは全体のビジネスプロセスがどのように構成されているか認識できないため、業務システムから発行させるイベントデータ（処理の開始や終了）に、他の業務システムとの繋がりを認識する情報を格納できない。そのため、ビジネスプロセスの変更により、業務システム全体の流れが変わったとしても、個々の業務システムではその変化を認識していないため、以前のビジネスプロセス時に発行したイベントと区別するための情報も格納できない。
【００６２】
また、異なるバージョンを区別するためにイベントデータの中にバージョン情報を付加する場合、それぞれの業務システムの改造が必要であると同時にそれぞれの業務システムでその業務システムが属するビジネスプロセスの変化を常に意識することが必要となる。そのため、既存システムを変更することなく運用することは不可能である。
【００６３】
これに対し、上述した実施の形態によれば、業務プロセスの変化があっても業務システムの変更が不要であり、個々の業務システムにおいて業務プロセスを意識する必要がない。また、最新の業務プロセスのイベントデータと過去の業務プロセスのイベントデータを区別して追跡することができ、業務モデルに正確に対応するイベント分析をおこなうことができる。また、現在運用中の業務モデルのバージョンに影響することなく、過去のバージョンのマイナーバージョンアップをすることが可能であり、過去のバージョンの業務モデルの誤りやコスト情報などの修正が現在の運用に影響なくおこなうことができる。
【００６４】
なお、本実施の形態で説明した業務プロセストラッキング処理は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
【００６５】
（付記１）複数の業務システム間の業務の流れを示す業務プロセスを追跡させる業務プロセストラッキングプログラムにおいて、
前記複数の業務システムによって定義される業務モデルにおける、現在運用中のバージョンから更新された更新後のバージョンの登録を受け付ける登録受付手段、
前記登録受付手段によって更新後のバージョンの登録が受け付けられた場合、前記現在運用中のバージョンの運用終了および前記更新後のバージョンの運用開始に関する時間情報を登録する登録手段、
としてコンピュータを機能させることを特徴とする業務プロセストラッキングプログラム。
【００６６】
（付記２）前記登録受付手段は、
前記業務モデルにおける非運用のバージョンから更新された更新後のバージョンの登録を受け付け、
前記登録手段は、
前記登録受付手段によって更新後のバージョンの登録が受け付けられた場合、前記非運用のバージョンの運用開始および運用終了に関する時間情報を更新後のバージョンの時間情報として登録することを特徴とする付記１に記載の業務プロセストラッキングプログラム。
【００６７】
（付記３）複数の業務システム間の業務の流れを示す業務プロセスを追跡させる業務プロセストラッキングプログラムにおいて、
前記複数の業務システムによって定義される業務モデルにおける、非運用のバージョンから更新された更新後のバージョンの登録を受け付ける登録受付手段、
前記登録受付手段によって更新後のバージョンの登録が受け付けられた場合、前記非運用のバージョンの運用開始および運用終了に関する時間情報を更新後のバージョンの時間情報として登録する登録手段、
としてコンピュータを機能させることを特徴とする業務プロセストラッキングプログラム。
【００６８】
（付記４）前記業務モデルのトラッキング対象となるバージョンを受け付けるトラッキング受付手段、
前記登録手段によって登録された時間情報の中から、前記トラッキング受付手段によって受け付けられたバージョンに合致するバージョンの時間情報を特定する特定手段と、
前記特定手段によって特定された時間情報に基づいて、前記業務プロセスの追跡を実行する実行手段、
としてコンピュータを機能させることを特徴とする付記１〜３のいずれか一つに記載の業務プロセストラッキングプログラム。
【００６９】
（付記５）付記１〜４のいずれか一つに記載の業務プロセストラッキングプログラムを記録したコンピュータに読み取り可能な記録媒体。
【００７０】
（付記６）複数の業務システム間の業務の流れを示す業務プロセスを追跡する業務プロセストラッキング装置において、
前記複数の業務システムによって定義される業務モデルにおける、現在運用中のバージョンから更新された更新後のバージョンの登録を受け付ける登録受付手段と、
前記登録受付手段によって更新後のバージョンの登録が受け付けられた場合、前記現在運用中のバージョンの運用終了および前記更新後のバージョンの運用開始に関する時間情報を登録する登録手段と、
を備えることを特徴とする業務プロセストラッキング装置。
【産業上の利用可能性】
【００７１】
以上のように、本発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置は、異なる業務システム間を跨いで行われる複数のアプリケーションからなる業務プロセスの流れを、既存システムを変更することなくトラッキングするシステムに有用である。
【図面の簡単な説明】
【００７２】
【図１】この発明の実施の形態にかかる業務プロセストラッキングシステムのシステム構成図である。
【図２】この発明の実施の形態にかかる業務プロセストラッキング装置等のハードウェア構成を示すブロック図である。
【図３】この発明の実施の形態にかかる業務モデルのバージョン変化推移を示す説明図である。
【図４−１】図３に示した各バージョンでの業務プロセスを示す説明図（その１）である。
【図４−２】図３に示した各バージョンでの業務プロセスを示す説明図（その２）である。
【図４−３】図３に示した各バージョンでの業務プロセスを示す説明図（その３）である。
【図４−４】図３に示した各バージョンでの業務プロセスを示す説明図（その４）である。
【図４−５】図３に示した各バージョンでの業務プロセスを示す説明図（その５）である。
【図５】この発明の実施の形態にかかるモデル版数管理テーブルの記憶内容を示す図表である。
【図６】この発明の実施の形態にかかる業務プロセストラッキング装置の機能的構成を示すブロック図である。
【図７】イベントＤＢの記憶内容の一例を示す説明図である。
【図８】この発明の実施の形態にかかるモデル版数管理テーブルの更新処理手順を示すフローチャートである。
【図９】この発明の実施の形態にかかる業務プロセストラッキング処理手順を示すフローチャートである。
【符号の説明】
【００７３】
１００  業務プロセストラッキングシステム
１０１  内部システム
１０２  業務プロセストラッキング装置
１０３  管理端末
１０４  トラッキング端末
３０１〜３０３  定義ファイル
５００  モデル版数管理テーブル
６０１  管理端末受付部
６０２  登録部
６０３  イベントデータ収集部
６０５  トラッキング端末受付部
６０６  特定部
６０７  トラッキング処理部
６０８  出力部
【図１】
2006293548.tif 000003
【図２】
2006293548.tif 000004
【図３】
2006293548.tif 000005
【図４−１】
2006293548.tif 000006
【図４−２】
2006293548.tif 000007
【図４−３】
2006293548.tif 000008
【図４−４】
2006293548.tif 000009
【図４−５】
2006293548.tif 000010
【図５】
2006293548.tif 000011
【図６】
2006293548.tif 000012
【図７】
2006293548.tif 000013
【図８】
2006293548.tif 000014
【図９】
2006293548.tif 000015