JP2006293547A - 業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置 - Google Patents

Abstract

【課題】業務プロセストラッキングの簡単かつ効率的に運用管理を図ること。
【解決手段】業務プロセストラッキング装置１０２において、各イベントデータ収集処理スレッドＴａ１〜Ｔａｎでは、それぞれ業務システムＷＳ１〜ＷＳｎからイベントデータを収集する。そして、格納処理スレッドＴｂでは、各イベントデータ収集処理スレッドＴａ１〜Ｔａｎによって収集されたイベントデータをデータベース３１０に格納する。また、管理端末１０３から処理の終了指示が受け付けられた場合、起動中のスレッドを終了する。たとえば、業務システムＷＳｉからのイベントデータ収集処理の起動指示（または終了指示）が受け付けられると、制御部３０２は、そのイベントデータ収集処理スレッドＴａｉを起動（または終了）させる。同様に、格納処理の終了指示が受け付けられると、制御部３０２は、格納処理スレッドＴｂを起動（または終了）させる。
【選択図】 図４

Description

この発明は、複数の業務システム間の業務の流れを示す業務プロセスを追跡する業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置に関する。

企業の成長に伴う業務システムの段階的導入や、ビジネスユニット単位での個別業務システムの導入により、企業内に複数の業務システムが存在するケースが多くなっている。これらの業務システムが複雑に関係し合うため、『業務全体の進捗を把握しにくい』、『業務プロセスの問題点がわからない』、『新規のＩＴ投資をどこに行うとどのような効果があるかわからない』といった問題が生じている。

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

また、異なる業務システムにまたがるようなワークフローや非定型業務についても、その履歴や進行状態の管理情報を参照したり、辿ったりすることを可能にするワークフロー支援システムおよび支援方法が開示されている（たとえば、下記特許文献１を参照。）。

特開平１０−６３７４７号公報

しかしながら、上述した従来技術では、途中で複数に分岐するアプリケーションの関係を把握することができないという問題があった。また、途中で複数に分岐するアプリケーションの関係を把握するためには、複数のプロセスに分割して別々に分析するなど、業務プロセスと分析方法の見直しが必要であった。

また、既存の多くの業務システムは、ワークフローにしたがって業務処理を追行しているわけではない。このため、異なる業務システム間の業務の流れを追跡する場合には、個々の業務システムにアクセスして処理済データ、未処理データなどのデータを収集し、分析しなければならず、業務の流れの追跡は現実には不可能であった。

この発明は、上述した従来技術による問題点を解消するため、複数の業務システム間の業務の流れを示す業務プロセスのトラッキングを、簡単かつ効率的に運用管理することができる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置を提供することを目的とする。

上述した課題を解決し、目的を達成するため、この発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置は、複数の業務システム間の業務の流れを示す業務プロセスを追跡させる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置において、前記業務プロセスのトラッキングに関する複数の処理を実行し、実行される複数の処理に関する起動動作または終了動作を、互いに独立しておこなうことを特徴とする。

また、上記発明において、前記複数の処理として、少なくとも、前記業務システムの実行状態に関するイベントデータを収集する前記業務システムごとの複数のイベントデータ収集処理を実行し、前記各イベントデータ収集処理に関する起動動作または終了動作を、互いに独立しておこなうこととしてもよい。

また、上記発明において、前記複数の処理として、さらに、前記各イベントデータ収集処理によって収集されるイベントデータを所定のデータベースに格納する格納処理を実行し、前記格納処理に関する起動動作または終了動作を、当該格納処理以外の他の処理とは独立しておこなうこととしてもよい。

また、上記発明において、前記格納処理の実行が停止した場合、前記各イベントデータ収集処理を停止するように制御することとしてもよい。

また、上記発明において、前記格納処理の実行が再開した場合、停止中の前記各イベントデータ収集処理の実行を再開することとしてもよい。

また、上記発明において、前記複数の処理として、少なくとも、前記業務プロセスを追跡する追跡処理を実行し、前記複数の処理のうち少なくともいずれか一つの処理の実行中に、前記追跡処理の起動を禁止することとしてもよい。

また、上記発明において、前記複数の処理として、少なくとも、前記所定のデータベースの中から前記業務プロセスの異常を示すアラートデータを収集するアラートデータ収集処理を実行し、前記アラートデータ収集処理の実行中に、前記追跡処理の起動を禁止することとしてもよい。

また、上記発明において、前記複数の処理として、少なくとも、前記所定のデータベースに格納されている情報を、他のデータベースにバックアップするバックアップ処理を実行し、前記バックアップ処理の実行中に、前記追跡処理の起動を禁止することとしてもよい。

また、上記発明において、前記複数の処理のうち少なくともいずれか一つの処理の実行中に、当該処理に設定されている優先度に基づいて、前記追跡処理の起動を禁止することとしてもよい。

また、上記発明において、前記業務プロセストラッキングプログラムの稼働状況に関する情報を取得し、取得された稼働状況に関する情報に基づいて、前記業務プロセスを追跡する追跡処理の起動を禁止することとしてもよい。

これらの発明によれば、各処理に対応する業務システムの状況に応じて、処理を起動または終了させることができる。また、格納処理とイベントデータ収集処理とを連動させることにより、無駄なイベントデータ収集処理を防止することができる。また、各処理の優先度に応じて、処理の実行許可または実行禁止を決定することができる。さらに、稼働状況を考慮して、現時点で実行させるべき処理のみの実行を許可し、実行させるべきでない処理を禁止することができる。

本発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置によれば、簡単かつ効率的に運用管理することができるという効果を奏する。

以下に添付図面を参照して、この発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置の好適な実施の形態を詳細に説明する。

（業務プロセストラッキングシステムのシステム構成）
まず、この発明の実施の形態にかかる業務プロセストラッキングシステムのシステム構成について説明する。図１は、この発明の実施の形態にかかる業務プロセストラッキングシステムのシステム構成図である。

図１において、業務プロセストラッキングシステム１００は、内部システム１０１と、業務システム群ＷＳと、バックアップサーバ１１０とが、インターネットやＷＡＮなどのネットワーク１２０を介して相互に交信可能に接続されている。

内部システム１０１は、業務プロセストラッキング装置１０２と、管理端末１０３と、トラッキング端末１０４が相互に交信可能に接続されており、ＬＡＮなどの内部ネットワークを構成している。また、業務プロセストラッキング装置１０２は、業務プロセスの追跡、監視、および管理をおこなう。管理端末１０３は、業務プロセストラッキング装置１０２の起動動作または終了動作の指示、追跡、監視、および管理に関する処理のスケジュール設定などをおこなう。トラッキング端末１０４は、業務プロセストラッキング装置１０２にアクセスして、目的とする業務プロセスの追跡要求、追跡対象の指定および追跡結果の表示をおこなう。

また、業務システム群ＷＳは、ある業務モデルにしたがって定義された複数（ｎ個）の異なる業務システムＷＳ１〜ＷＳｎの集合である。個々の業務システムＷＳｉは、他の業務システムＷＳｊ（ｊ≠ｉ）の作業状況を把握していない。ここで、業務システム群ＷＳの業務システム数ＷＳ１〜ＷＳｎのｎをｎ＝４として簡単に説明すると、たとえば、商品の注文から製造販売まで手がける業務モデルである場合、受発注システム（業務システムＷＳ１）、在庫管理システム（業務システムＷＳ２）、生産システム（業務システムＷＳ３）、および出荷システム（業務システムＷＳ４）の４つの業務システムによって構成することができる。ここで、業務プロセスとは、業務システムＷＳ１〜ＷＳｎ間の業務の流れを示しているため、この場合の業務プロセスとは、たとえば、ある商品の受発注処理から、在庫管理処理、生産処理、出荷処理までの一連の処理である。

実際には、業務システムＷＳ１〜ＷＳｎの数ｎは、数十個〜百個以上有するものもあり、追跡対象となる業務プロセスも大規模化、多様化している。本実施の形態では、このように大規模化、多様化した業務プロセスについても、追跡、監視および管理の効率化を図ることができる。また、バックアップサーバ１１０は、業務プロセストラッキング装置１０２に記憶されている情報をバックアップする。

（業務プロセストラッキング装置１０２等のハードウェア構成）
まず、この発明の実施の形態にかかる業務プロセストラッキング装置１０２、管理端末１０３、トラッキング端末１０４、バックアップサーバ１１０、各業務システムＷＳ１〜ＷＳｎ（以下、「業務プロセストラッキング装置１０２等」という）のハードウェア構成について説明する。図２は、この発明の実施の形態にかかる業務プロセストラッキング装置１０２等のハードウェア構成を示すブロック図である。

図２において、業務プロセストラッキング装置１０２等は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、ＨＤＤ（ハードディスクドライブ）２０４と、ＨＤ（ハードディスク）２０５と、ＦＤＤ（フレキシブルディスクドライブ）２０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）２０７と、ディスプレイ２０８と、Ｉ／Ｆ（インターフェース）２０９と、キーボード２１０と、マウス２１１と、スキャナ２１２と、プリンタ２１３と、を備えている。また、各構成部はバス２００によってそれぞれ接続されている。

ここで、ＣＰＵ２０１は、業務プロセストラッキング装置１０２等の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。ＨＤＤ２０４は、ＣＰＵ２０１の制御にしたがってＨＤ２０５に対するデータのリード／ライトを制御する。ＨＤ２０５は、ＨＤＤ２０４の制御で書き込まれたデータを記憶する。

ＦＤＤ２０６は、ＣＰＵ２０１の制御にしたがってＦＤ２０７に対するデータのリード／ライトを制御する。ＦＤ２０７は、ＦＤＤ２０６の制御で書き込まれたデータを記憶したり、ＦＤ２０７に記憶されたデータを業務プロセストラッキング装置１０２等に読み取らせたりする。

また、着脱可能な記録媒体として、ＦＤ２０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ２０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ２０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ２０９は、通信回線を通じてインターネットなどのネットワーク１２０に接続され、このネットワーク１２０を介して他の装置に接続される。そして、Ｉ／Ｆ２０９は、ネットワーク１２０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード２１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス２１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ２１２は、画像を光学的に読み取り、業務プロセストラッキング装置１０２等内に画像データを取り込む。なお、スキャナ２１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ２１３は、画像データや文書データを印刷する。プリンタ２１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（業務プロセストラッキング装置１０２の機能的構成）
つぎに、この発明の実施の形態にかかる業務プロセストラッキング装置１０２の機能的構成について説明する。図３は、この発明の実施の形態にかかる業務プロセストラッキング装置１０２の機能的構成を示すブロック図である。図３において、業務プロセストラッキング装置１０２は、実行部３０１と、制御部３０２と、取得部３０３と、データベース３１０と、から構成されている。

まず、実行部３０１は、収集／格納エンジン３１１と、検索エンジン３１２とを備えている。収集／格納エンジン３１１は、各業務システムＷＳ１〜ＷＳｎからイベントデータを収集したり、収集したイベントデータをデータベース３１０に格納する。また、データベース３１０内のイベントデータからアラートデータを収集することもできる。また、データベース３１０内のイベントデータをバックアップサーバ１１０のデータベース３２０に移行してバックアップすることもできる。ここで、イベントデータとは、各業務システムＷＳ１〜ＷＳｎ内において、その業務の実行内容に関するデータであり、業務を遂行した時刻、その他当該業務に関する情報を含むデータである。

たとえば、業務システムＷＳｉが受発注システムＷＳ１である場合、イベントデータには、受発注担当者の識別情報（担当者名や担当者コード）、受注した商品の識別情報（商品名や商品コード）、商品の受注時刻と後続の業務システム（在庫管理システムＷＳ２や生産システムＷＳ３）へ知らせる発注時刻、商品の受注数量、金額などが含まれている。

また、業務システムＷＳｉが在庫管理システムＷＳ２である場合、イベントデータには、在庫管理担当者の識別情報（担当者名や担当者コード）、在庫管理対象商品の識別情報（商品名や商品コード）、在庫管理の確認時刻、在庫管理対象商品の在庫数などが含まれている。

また、業務システムＷＳｉが生産システムＷＳ３である場合、イベントデータには、生産担当者の識別情報（担当者名や担当者コード）、生産対象商品の識別情報（商品名や商品コード）、生産数量、進捗状況（生産開始日時、生産完了の有無、残り生産個数、単位時間あたりの生産個数、生産完了予定日時、生産完了日時）などが含まれている。

また、業務システムＷＳｉが出荷システムＷＳ４である場合、イベントデータには、出荷担当者の識別情報（担当者名や担当者コード）、生産対象商品の識別情報（商品名や商品コード）、出荷予定日、出荷の有無などが含まれている。

また、アラートデータとは、各業務システムＷＳ１〜ＷＳｎの異常や警告を示す情報である。たとえば、業務システムＷＳｉが受発注システムＷＳ１である場合、ある商品を受注してから所定時間以上経過しても生産システムＷＳ３に発注されていない旨のアラートデータを、データベース３１０内のイベントデータから収集することができる。

また、業務システムＷＳｉが在庫管理システムＷＳ２である場合、在庫数が所定数以下の商品または当該商品の在庫数を含むアラートデータを、データベース３１０内のイベントデータから収集することができる。また、業務システムＷＳｉが生産システムＷＳ３である場合、単位時間あたりの生産個数が所定個数以下である旨のアラートデータを、データベース３１０内のイベントデータから収集することができる。また、業務システムＷＳｉが出荷システムＷＳ４である場合、出荷予定日の遅延情報をアラートデータとしてデータベース３１０内のイベントデータから収集することができる。

また、検索エンジン３１２は、トラッキング端末１０４からの業務プロセスの追跡依頼を受け付けて、データベース３１０を検索する。たとえば、トラッキング端末１０４から追跡対象商品の識別情報を受け付けると、その追跡対象商品に関するイベントデータを、データベース３１０から検索する。この検索内容を時系列にして追跡依頼をしたトラッキング端末１０４に出力することにより、トラッキング端末１０４の表示画面に追跡結果として表示することができる。

また、制御部３０２は、あらかじめ設定されたスケジュールにしたがって、実行部３０１を制御する。具体的には、実行部３０１の収集／格納エンジン３１１によって実行される業務システムＷＳ１〜ＷＳｎごとのイベントデータ収集処理、イベントデータ格納処理、アラートデータ収集処理およびバックアップ処理や、検索エンジン３１２による追跡処理の実行を制御する。具体的には、たとえば、ある処理の開始時刻になった場合、当該処理が実行され、当該処理の終了時刻になった場合、実行を終了する。

また、管理端末１０３からある処理の起動指示が受け付けられた場合、当該処理を起動して実行状態とし、実行中のある処理の終了指示が受け付けられた場合、当該処理の実行を終了する。また、制御部３０２は、あらかじめ設定された各処理の優先度に基づいて、実行可能な処理と実行不可能な処理を決定して実行部３０１を制御することもできる。

また、取得部３０３は、業務プロセストラッキング装置１０２の稼働状況に関する情報（以下、「稼働状況情報」という）を取得する。ここで、稼働状況情報とは、たとえば、業務プロセストラッキング装置１０２を構成するＣＰＵ２０１と、ＲＡＭ２０３などのメモリの使用率など、業務プロセストラッキング装置１０２の負荷を示す情報が挙げられる。制御部３０２は、このＣＰＵ２０１またはメモリの使用率から、実行可能な処理と実行不可能な処理を決定して実行部３０１を制御することもできる。なお、上述した実行部３０１、制御部３０２および取得部３０３は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ＨＤ２０５などの記録媒体に記録されたプログラムを、ＣＰＵ２０１が実行することによって、またはＩ／Ｆ２０９によって、その機能を実現する。

つぎに、実行部３０１による各業務システムＷＳ１〜ＷＳｎに対するイベントデータ収集処理と格納処理について説明する。図４は、実行部３０１による各業務システムＷＳ１〜ＷＳｎに対するイベントデータ収集処理と格納処理を示す説明図である。図４において、スケジュールによりイベントデータ収集処理の開始時刻になった場合、収集／格納エンジン３１１は、業務システムＷＳ１〜ＷＳｎごとにイベントデータ収集処理スレッドＴａ（Ｔａ１〜Ｔａｎ）を立ち上げる。また、スケジュールによりイベントデータ収集処理の終了時刻になった場合、収集／格納エンジン３１１は、業務システムＷＳ１〜ＷＳｎごとにイベントデータ収集処理スレッドＴａ（Ｔａ１〜Ｔａｎ）を終了する。

同様に、スケジュールにより格納処理の開始時刻になった場合、収集／格納エンジン３１１は、格納処理スレッドＴｂを立ち上げる。また、スケジュールによりイベントデータ収集処理の終了時刻になった場合、収集／格納エンジン３１１は、格納処理スレッドＴｂを終了する。このような複数のスレッドＴａ、Ｔｂの立ち上げは、たとえば、Ｊａｖａ（登録商標）によるｍｕｌｔｉ Ｔｈｒｅａｄ Ｐｒｏｇｒａｍｍｉｎｇなどを用いることにより実現することができる。

また、各イベントデータ収集処理スレッドＴａ１〜Ｔａｎでは、それぞれ業務システムＷＳ１〜ＷＳｎからイベントデータを収集する。そして、格納処理スレッドＴｂでは、各イベントデータ収集処理スレッドＴａ１〜Ｔａｎによって収集されたイベントデータをデータベース３１０に格納する。また、管理端末１０３から処理の終了指示が受け付けられた場合、起動中のスレッドを終了する。たとえば、業務システムＷＳｉからのイベントデータ収集処理の起動指示（または終了指示）が受け付けられると、制御部３０２は、そのイベントデータ収集処理スレッドＴａｉを起動（または終了）させる。同様に、格納処理の終了指示が受け付けられると、制御部３０２は、格納処理スレッドＴｂを起動（または終了）させる。

このように、業務プロセストラッキング装置１０２や業務システムＷＳｉのメンテナンスがある場合や、業務システムＷＳｉの情報変更などがある場合、スレッドごとに個別に起動または終了することができるため、他の業務システムＷＳｊ（ｊ≠ｉ）からのイベントデータ収集処理を継続して実行することができる。

また、管理する業務システム群ＷＳが多様化しスケジュールの制御が複雑化した場合でも、各イベントデータ収集処理スレッドＴａ１〜Ｔａｎは、格納処理スレッドＴｂの起動状態を監視して、格納処理スレッドＴｂの停止に連動して各業務システムＷＳ１〜ＷＳｎに対するイベントデータ収集処理スレッドＴａ１〜Ｔａｎを停止するため、各業務システムＷＳ１〜ＷＳｎの起動状態を意識することなく、データベース３１０のメンテナンスや情報変更などを実施することができる。

この場合も上述したように、たとえば、Ｍｕｌｔｉ Ｔｈｒｅａｄ Ｐｒｏｇｒａｍｍｉｎｇを用いて、分離された各イベントデータ収集処理スレッドＴａ１〜Ｔａｎが格納処理スレッドＴｂの状態を定期的に監視して、格納処理スレッドＴｂの状態によってイベントデータ収集処理の停止／再開をおこなうことができる。

つぎに、実行部３０１によるアラートデータ収集処理および追跡処理について説明する。図５は、実行部３０１によるアラートデータ収集処理および追跡処理を示す説明図である。図５において、スケジュールによりアラートデータ収集処理の開始時刻になった場合、収集／格納エンジン３１１は、アラートデータ収集処理スレッドＴｃを立ち上げて、データベース３１０からアラートデータを収集する。そして、アラートデータをすべて収集すると、アラートデータ収集処理スレッドＴｃを終了する。

また、トラッキング端末１０４からの追跡指示を受け付けると、検索エンジン３１２か追跡処理スレッドＴｄを立ち上げて、上述したように、トラッキング端末１０４からの業務プロセスの追跡依頼を受け付けて、データベース３１０を検索する。この検索により、イベントデータやアラートデータを抽出して、追跡結果としてトラッキング端末１０４に出力する。

つぎに、実行部３０１によるバックアップ処理について説明する。図６は、実行部３０１によるバックアップ処理を示す説明図である。図６において、スケジュールによりバックアップ処理の開始時刻になった場合、収集／格納エンジン３１１は、バックアップ処理スレッドＴｅを立ち上げて、データベース３１０内の情報を、バックアップサーバ１１０に転送する。これによりデータベース３１０内の情報が、バックアップサーバ１１０のデータベース３２０に移行することができる。また、バックアップ処理が完了すると、バックアップ処理スレッドＴｅを終了する。

つぎに、上述したスケジュールについて説明する。図７は、スケジュールを示す説明図である。このスケジュール７００は、制御部３０２で参照され、制御部３０２はこのスケジュール７００にしたがって実行部３０１を制御する。図７において、処理項目７０１には、スレッドとして立ち上がる処理の名称が示されている。また、タイプ項目７０２には、処理の実行周期、たとえば、『毎日』、『毎週』が示されている。

また、曜日項目７０３には、処理を実行する曜日が示されている。また、開始時刻項目７０４には、処理の開始時刻が、終了時刻項目７０５には、処理の終了項目が示されている。たとえば、イベントデータ収集処理は、毎週月曜日から金曜日の１２：００にイベントデータ収集処理スレッドＴａを起動し、１７：００にイベントデータ収集処理スレッドＴａを終了する。なお、追跡処理に関しては、毎日１３：００から１７：００まで、トラッキング端末１０４から追跡処理スレッドＴｄを起動することができることを意味している。このスケジュール７００の内容は、たとえば、ＸＭＬ形式の電子文書で管理端末１０３を操作することで設定することができる。

（業務プロセストラッキング処理手順）
つぎに、この発明の実施の形態にかかる業務プロセストラッキング処理手順（その１）について説明する。図８は、この発明の実施の形態にかかる業務プロセストラッキング処理手順（その１）を示すフローチャートである。図８において、管理端末１０３から動作指示入力があった場合（ステップＳ８０１：Ｙｅｓ）、指示対象処理を判断する（ステップＳ８０２）。指示対象処理が任意の業務システムのイベントデータ収集処理である場合（ステップＳ８０２：イベントデータ収集処理）、動作指示を判断する（ステップＳ８０３）。

動作指示が起動指示である場合（ステップＳ８０３：起動）、動作指示対象の業務システムＷＳｉのイベントデータ収集処理スレッドＴａｉを起動する（ステップＳ８０４）。一方、動作指示が終了指示である場合（ステップＳ８０３：終了）、動作指示対象の業務システムＷＳｉのイベントデータ収集処理スレッドＴａｉを終了する（ステップＳ８０５）。

また、ステップＳ８０２において、指示対象処理が格納処理である場合（ステップＳ８０２：格納処理）、動作指示を判断する（ステップＳ８０６）。動作指示が起動指示である場合（ステップＳ８０６：起動）、格納処理スレッドＴｂを起動する（ステップＳ８０７）。一方、動作指示が終了指示である場合（ステップＳ８０６：終了）、格納処理スレッドＴｂを終了する（ステップＳ８０８）。

このように、業務プロセストラッキング装置１０２や業務システムＷＳ１〜ＷＳｎのメンテナンスがある場合や、業務システムＷＳｉの情報変更などがある場合、スレッドごとに個別に起動または終了することができるため、他の業務システムＷＳｊ（ｊ≠ｉ）からのイベントデータ収集処理を継続して実行することができる。

つぎに、この発明の実施の形態にかかる業務プロセストラッキング処理手順（その２）について説明する。図９は、この発明の実施の形態にかかる業務プロセストラッキング処理手順（その２）を示すフローチャートである。図９において、イベントデータ収集処理が実行中である場合（ステップＳ９０１：Ｙｅｓ）、格納処理が停止中であるか否かを判断する（ステップＳ９０２）。

格納処理が停止中である場合（ステップＳ９０２：Ｙｅｓ）、実行中のイベントデータ収集処理を停止し（ステップＳ９０３）、ステップＳ９０１に移行してイベントデータ収集処理が実行中であるか否か判断する。また、ステップＳ９０２において、格納処理が停止中でない場合も（ステップＳ９０２：Ｎｏ）、ステップＳ９０１に移行してイベントデータ収集処理が実行中であるか否か判断する。

一方、ステップＳ９０１において、イベントデータ収集処理が実行中でない場合（ステップＳ９０１：Ｎｏ）、格納処理スレッドＴｂが起動しているか否かを判断する（ステップＳ９０４）。格納処理スレッドＴｂが起動している場合（ステップＳ９０４：Ｙｅｓ）、停止中のイベントデータ収集処理を再開し（ステップＳ９０５）、ステップＳ９０１に移行してイベントデータ収集処理が実行中であるか否か判断する。また、ステップＳ９０４において、格納処理スレッドＴｂが起動していない場合も（ステップＳ９０４：Ｎｏ）、ステップＳ９０１に移行してイベントデータ収集処理が実行中であるか否か判断する。

このように、管理する業務システム群ＷＳが多様化しスケジュール７００の制御が複雑化した場合でも、各イベントデータ収集処理スレッドＴａ１〜Ｔａｎは、格納処理スレッドＴｂの起動状態を監視して、格納処理スレッドＴｂの停止に連動して各業務システムＷＳ１〜ＷＳｎに対するイベントデータ収集処理スレッドＴａ１〜Ｔａｎを停止することができる。したがって、各業務システムＷＳ１〜ＷＳｎの起動状態を意識することなく、データベース３１０のメンテナンスや情報変更などを実施することができる。

つぎに、この発明の実施の形態にかかる業務プロセストラッキング処理手順（その３）について説明する。この業務プロセストラッキング処理手順では、処理ごとに設定された優先度と、ＣＰＵ２０１やメモリの使用率などの稼働状況情報とを用いた業務プロセストラッキング処理手順である。図１０は、各処理と優先度との対応関係を示す図表であり、図１１は、条件設定ファイルを示す図表であり、図１２は、この発明の実施の形態にかかる業務プロセストラッキング処理手順（その３）を示すフローチャートである。

図１０において、処理ごとに優先度１〜５が設定されている。優先度１の処理が最も優先される処理である。また、図１１において、条件設定ファイル１１００は、業務プロセストラッキング装置１０２の稼働状況と制御部３０２による制御内容との対応関係を示している。この条件設定ファイル１１００において、稼働状況情報は、ＣＰＵ２０１の使用率（ＣＰＵ使用率）とメモリの使用率（メモリ使用率）とのＡＮＤ／ＯＲによって定義されている。

たとえば、条件Ａ、すなわち、ＣＰＵ使用率が１００％以上でかつメモリ使用率が８０％以上である場合、制御部３０２は、優先度１以下の処理、図１０に示したすべての処理を停止する。また、条件Ｃ、すなわち、ＣＰＵ使用率またはメモリ使用率のいずれかが６５％以上である場合、優先度３以下の処理、すなわち、追跡処理（優先度３）、アラートデータ収集処理（優先度４）およびバックアップ処理（優先度５）を停止する。

つぎに、図１２に示したフローチャートについて説明する。図１２において、複数種類の処理が実行中であるか否かを判断する（ステップＳ１２０１）。複数種類の処理が実行中でない場合（ステップＳ１２０１：Ｎｏ）、すなわち、実行中の処理が１つ、または複数の処理が実行中であっても１種類の処理（たとえば、イベントデータ収集処理）である場合には、複数種類の処理が実行中となるまで、ステップＳ１２０１の判断を繰り返す。

複数種類の処理が実行中である場合（ステップＳ１２０１：Ｙｅｓ）、条件設定ファイル１１００を読み込み、稼働状況情報を取得する（ステップＳ１２０２）。つぎに、図１１に示した稼働状況情報に合致する条件があるか否かを判断する（ステップＳ１２０３）。合致する条件がない場合（ステップＳ１２０３：Ｎｏ）、ステップＳ１２０１に移行する。

一方、合致する条件がある場合（ステップＳ１２０３：Ｙｅｓ）、合致する条件に従って、実行中の複数種類の処理を制御する（ステップＳ１２０４）。たとえば、ＣＰＵ使用率が６７％でメモリ使用率が５０％であれば、図１１に示した条件Ｃに合致するため、優先度３以下の処理、すなわち、追跡処理（優先度３）、アラートデータ収集処理（優先度４）およびバックアップ処理（優先度５）を停止する。

このように、業務プロセストラッキング装置１０２のＣＰＵ２０１やメモリの負荷を示す稼働状況情報を取得することにより、同時並行処理による業務プロセストラッキング装置１０２の負荷増大の防止を図ることができる。特に、各処理の優先度を考慮することにより、処理の効率化を図ることができる。たとえば、業務プロセストラッキング装置１０２への負荷をある程度犠牲にしてもリアルタイムな追跡結果を要求する場合、イベントデータ収集処理と重複しても追跡処理の実行が許可されるため、正確な追跡結果をリアルタイムで取得することができる。一方、業務プロセストラッキング装置１０２の負荷が条件Ｃに合致する場合には、イベントデータ収集処理の実行を許可しつつ、追跡処理の実行を禁止する。これにより、業務プロセストラッキング装置１０２の負荷の軽減を図ることができる。

なお、図１１に示したように、業務プロセストラッキング装置１０２のＣＰＵ２０１やメモリの負荷を示す稼働状況情報を用いる場合、瞬間的にＣＰＵ使用率またはメモリ使用率が増加するため、所定間隔でＣＰＵ使用率またはメモリ使用率の平均値を算出し、算出された平均値が条件Ａ〜Ｅに合致するか否かを判断する。これにより、制御部３０２の誤動作を防止することができる。

以上説明したように、この発明の実施の形態にかかる業務プロセストラッキング装置１０２によれば、追跡対象の業務プロセスが大規模化・多様化するに伴って、管理対象となる業務システムＷＳ１〜ＷＳｎの数ｎが増加しても、メンテナンス時や業務システムＷＳ１〜ＷＳｎの情報変更などの場合に、業務システムＷＳ１〜ＷＳｎごとにイベントデータ収集処理を終了させることができるため、業務プロセストラッキング装置１０２の操作性向上を図ることができる。

イベントデータ収集処理の実行中に格納処理スレッドＴｂが停止した場合には、収集されたイベントデータをデータベース３１０に格納することができないため、格納処理の停止を自動検出することにより、イベントデータ収集処理スレッドＴａを停止することができる。したがって、無駄なイベントデータ収集処理を防止することにより、業務プロセストラッキング装置１０２の負荷の軽減を図ることができる。

また、優先度に応じて、または稼働状況（業務プロセストラッキング装置１０２の負荷）を監視することにより、同時並行して実行できる処理を設定することができ、効率的なトラッキング処理を実現することができる。

なお、上述した実施の形態では、図１０に示した処理の優先度と、図１１に示した条件設定ファイル１１００とを用いて、実行部３０１を制御することとしているが、図１０に示した処理の優先度のみを用いて、実行部３０１を制御することもできる。たとえば、ある処理の実行中に他の処理が起動する場合、あらたに起動する処理の優先度が、実行中の処理の優先度より高ければ起動を許可し、低ければ起動を禁止するという制御をおこなうこともできる。これにより、優先度に応じて処理の実行を制御することができ、効率的なトラッキングの管理をおこなうことができる。

なお、本実施の形態で説明した業務プロセストラッキング処理は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。

（付記１）複数の業務システム間の業務の流れを示す業務プロセスを追跡させる業務プロセストラッキングプログラムにおいて、
前記業務プロセスのトラッキングに関する複数の処理を実行する実行手段、
前記実行手段を制御して、前記実行手段によって実行される複数の処理に関する起動動作または終了動作を、互いに独立しておこなう制御手段、
としてコンピュータを機能させることを特徴とする業務プロセストラッキングプログラム。

（付記２）前記実行手段は、
前記複数の処理として、少なくとも、前記業務システムの実行状態に関するイベントデータを収集する前記業務システムごとの複数のイベントデータ収集処理を実行し、
前記制御手段は、
前記各イベントデータ収集処理に関する起動動作または終了動作を、互いに独立しておこなうことを特徴とする付記１に記載の業務プロセストラッキングプログラム。

（付記３）前記実行手段は、
前記複数の処理として、さらに、前記各イベントデータ収集処理によって収集されるイベントデータを所定のデータベースに格納する格納処理を実行し、
前記制御手段は、
前記格納処理に関する起動動作または終了動作を、当該格納処理以外の他の処理とは独立しておこなうことを特徴とする付記１に記載の業務プロセストラッキングプログラム。

（付記４）前記制御手段は、
前記格納処理の実行が停止した場合、前記各イベントデータ収集処理を停止するように制御することを特徴とする付記３に記載の業務プロセストラッキングプログラム。

（付記５）前記制御手段は、
前記格納処理の実行が再開した場合、停止中の前記各イベントデータ収集処理の実行を再開することを特徴とする付記４に記載の業務プロセストラッキングプログラム。

（付記６）前記実行手段は、
前記複数の処理として、少なくとも、前記業務プロセスを追跡する追跡処理を実行し、
前記制御手段は、
前記複数の処理のうち少なくともいずれか一つの処理の実行中に、前記追跡処理の起動を禁止することを特徴とする付記１に記載の業務プロセストラッキングプログラム。

（付記７）前記実行手段は、
前記複数の処理として、少なくとも、前記所定のデータベースの中から前記業務プロセスの異常を示すアラートデータを収集するアラートデータ収集処理を実行し、
前記制御手段は、
前記アラートデータ収集処理の実行中に、前記追跡処理の起動を禁止することを特徴とする付記６に記載の業務プロセストラッキングプログラム。

（付記８）前記実行手段は、
前記複数の処理として、少なくとも、前記所定のデータベースに格納されている情報を、他のデータベースにバックアップするバックアップ処理を実行し、
前記制御手段は、
前記バックアップ処理の実行中に、前記追跡処理の起動を禁止することを特徴とする付記６または７に記載の業務プロセストラッキングプログラム。

（付記９）前記制御手段は、
前記複数の処理のうち少なくともいずれか一つの処理の実行中に、当該処理に設定されている優先度に基づいて、前記追跡処理の起動を禁止することを特徴とする付記６に記載の業務プロセストラッキングプログラム。

（付記１０）前記業務プロセストラッキングプログラムの稼働状況に関する情報を取得する取得手段を備え、
前記制御手段は、
さらに、取得手段によって取得された稼働状況に関する情報に基づいて、前記業務プロセスを追跡する追跡処理の起動を禁止することを特徴とする付記９に記載の業務プロセストラッキングプログラム。

（付記１１）付記１〜１０のいずれか一つに記載の業務プロセストラッキングプログラムを記録したコンピュータに読み取り可能な記録媒体。

（付記１２）複数の業務システム間の業務の流れを示す業務プロセスを追跡する業務プロセストラッキング装置において、
前記業務プロセスのトラッキングに関する複数の処理を実行する実行手段と、
前記実行手段を制御して、前記実行手段によって実行される複数の処理に関する起動動作または終了動作を、互いに独立しておこなう制御手段と、
を備えることを特徴とする業務プロセストラッキング装置。

以上のように、本発明にかかる業務プロセストラッキングプログラム、該プログラムを記録した記録媒体、および業務プロセストラッキング装置は、異なる業務システム間を跨いで行われる複数のアプリケーションからなる業務プロセスの流れを、既存システムを変更することなくトラッキングするシステムに有用である。

この発明の実施の形態にかかる業務プロセストラッキングシステムのシステム構成図である。 この発明の実施の形態にかかる業務プロセストラッキング装置等のハードウェア構成を示すブロック図である。 この発明の実施の形態にかかる業務プロセストラッキング装置の機能的構成を示すブロック図である。 実行部による各業務システムに対するイベントデータ収集処理と格納処理を示す説明図である。 実行部によるアラートデータ収集処理および追跡処理を示す説明図である。 実行部によるバックアップ処理を示す説明図である。 スケジュールを示す説明図である。 この発明の実施の形態にかかる業務プロセストラッキング処理手順（その１）を示すフローチャートである。 この発明の実施の形態にかかる業務プロセストラッキング処理手順（その２）を示すフローチャートである。 各処理と優先度との対応関係を示す図表である。 条件設定ファイルを示す図表である。 この発明の実施の形態にかかる業務プロセストラッキング処理手順（その３）を示すフローチャートである。

符号の説明

１００ 業務プロセストラッキングシステム
１０２ 業務プロセストラッキング装置
１０３ 管理端末
１０４ トラッキング端末
１１０ バックアップサーバ
３０１ 実行部
３０２ 制御部
３０３ 取得部
３１０ データベース
３１１ 収集／格納エンジン
３１２ 検索エンジン
７００ スケジュール
１１００ 条件設定ファイル
Ｔａ（Ｔａ１〜Ｔａｎ） イベントデータ収集処理スレッド
Ｔｂ 格納処理スレッド
Ｔｃ アラートデータ収集処理スレッド
Ｔｄ 追跡処理スレッド
Ｔｅ バックアップ処理スレッド
ＷＳ 業務システム群

Claims (5)

1. 複数の業務システム間の業務の流れを示す業務プロセスを追跡させる業務プロセストラッキングプログラムにおいて、
   前記業務プロセスのトラッキングに関する複数の処理を実行する実行手段、
   前記実行手段を制御して、前記実行手段によって実行される複数の処理に関する起動動作または終了動作を、互いに独立しておこなう制御手段、
   としてコンピュータを機能させることを特徴とする業務プロセストラッキングプログラム。
2. 前記実行手段は、
   前記複数の処理として、少なくとも、前記業務システムの実行状態に関するイベントデータを収集する前記業務システムごとの複数のイベントデータ収集処理を実行し、
   前記制御手段は、
   前記各イベントデータ収集処理に関する起動動作または終了動作を、互いに独立しておこなうことを特徴とする請求項１に記載の業務プロセストラッキングプログラム。
3. 前記実行手段は、
   前記複数の処理として、さらに、前記各イベントデータ収集処理によって収集されるイベントデータを所定のデータベースに格納する格納処理を実行し、
   前記制御手段は、
   前記格納処理に関する起動動作または終了動作を、当該格納処理以外の他の処理とは独立しておこなうことを特徴とする請求項１に記載の業務プロセストラッキングプログラム。
4. 請求項１〜３のいずれか一つに記載の業務プロセストラッキングプログラムを記録したコンピュータに読み取り可能な記録媒体。
5. 複数の業務システム間の業務の流れを示す業務プロセスを追跡する業務プロセストラッキング装置において、
   前記業務プロセスのトラッキングに関する複数の処理を実行する実行手段と、
   前記実行手段を制御して、前記実行手段によって実行される複数の処理に関する起動動作または終了動作を、互いに独立しておこなう制御手段と、
   を備えることを特徴とする業務プロセストラッキング装置。
   

Images