JP2008003732A - 操作ログによる業務シナリオ通知機能 - Google Patents

Abstract

【課題】コンピュータシステムにおける業務判定を行う場合、プログラムへの組み込みが主であるため、業務の変更や追加、削除が発生した場合、それを実現するための時間と費用がかかり、急な業務変更に耐えられなかった。
【解決手段】アプリケーションが出力する操作ログから、予め対応された業務を登録することによる、登録された業務内容を出力する。これにより、プログラム改修を行わずに業務の追加、修正、削除に対応する。また、開始日、終了日の検索もSQLにより実現することから、詳細な業務内容変更に対応することができる。
【選択図】図１

Description

本発明は、コンピュータを使用した各種業務における、次工程の判断をコンピュータに行わせるものであり、特に、既存の操作ログより業務を判定する機能を有し、業務内容を予め使用者で登録できることに関する。

コンピュータシステムで、ある業務を行う時、業務の順序をオペレータに通知したい時、紙のマニュアルによる指示か、入力内容によって、次の業務を強制的に起動するプログラミングによる対応か、オペレータのアクションによるヘルプシステム起動で次の業務プログラムへの遷移を知る方法が一般的である。

また、各種業務は、開始時期や、終了期限が設けられている場合が多く、これらの納期管理的項目は必須である。

しかし、これらの方法は、業務遷移やルールが変更された時、マニュアルの修正と配布・教育や、プログラミングの修正や、ヘルプシステムの内容修正と配布など、費用や期間がかかることがある。

また、他のシステムへの適用ができず、資源が浪費されることが多かった。

そこで、ユーザーのアクションを監視し、ユーザーがどのアイテムに対してどのように作業を行ったかを示すアクション情報を記録し、使用されたアイテム毎の情報に関するファイルを作成する。使用されたアイテム毎に少なくとも他のアイテムとの関連性を表す情報を、過去に行われた業務処理手順などに基づいて業務処理モデルが自動的に作成できるようにした。

特開2002−215857号公報

かかる従来の方法においては、次のような問題点がある。

すなわち、全てがシステム自動であり、人間の処理する曖昧さを吸収できない。

また、業務に関する期間の指定（開始日、終了日）ができない。

また、アクションを監視するという処理があるため、導入できるコンピュータシステムが限られてしまう。

また、大きな業務変更が発生した場合、自動処理ロジックの変更が発生する場合がある。この時、仕様の決定、仕様の作成、プログラム作成、テストと多岐にわたる工程を踏むことになり、迅速な対応ができなくなる。また、プログラム改修によるバグの発生も考えられる。また、改修後にもユーザーの要望により変更される場合もよくあることである。

また、他のシステムに同様の仕組みを構築しようとする場合もプログラミングの修正が多岐にわたることが考えられる。

本発明の目的は、既に存在しているコンピュータ業務システムに、シナリオ通知機能を容易に、迅速に導入できることにある。

また、本発明を適用済みのコンピュータシステムにおいては、業務内容（通知するシナリオ情報）の変更・削除・追加という、ビジネス上よく発生する事象に、迅速に且つ、容易・安価に対応できることを目的とする。

本発明は、個人情報保護の観点によりアプリケーションが全ての操作ログを出力するようになった、2005年4月以降に動作しているコンピュータシステムを対象として、それらが出力する操作ログと、業務を関連付けることにより、プログラム改修を実施せずに、業務フローの追加、変更、削除に対応するものである。
図

にあるように、個人情報保護に対応したアプリケーションは、入力オぺレーション結果を格納するデータベースと、操作内容を記録するログを出力することが一般的である。例として、顧客管理システムにおける、顧客住所メンテナンスという画面が住所データを更新・追加・削除する時の操作ログ出力例を示した。

ここで、顧客情報メンテナンス２１で、顧客番号により顧客を特定し、その住所を表示、入力したとき、その内容を住所データ２３の顧客番号、住所、更新日を更新し、同時に操作ログ２２の日時、担当者、画面名、顧客番号、処理結果を追加する処理を示した。

この操作ログ内容により、次の業務を確定させることで、オペレータの負荷を低減させることが可能となる。

また、開始日付、終了日付を付加することが可能であるので、各業務の納期的管理にも利用することができる。

また、シナリオマスターのメンテナンスで、業務内容を変更できることから、大規模な業務内容変更にも、プログラム改修を行うことなく対応が可能となる。

例えば、Aという操作ログが出力された場合、次はBという業務を実施したいたが、Cという業務に変更したい場合（業務の変更）があるとすると、シナリオマスター６４の、業務内容を変更すれば業務変更に対応できることになる。

また、新たな業務Dは、業務Cを実施した後で行う（業務の追加）ことになった場合、シナリオマスターの各項目を設定することにより可能となる。

また、業務Eの後に実施していた、業務Fが無くなった場合（業務の削除）、シナリオマスター６４に業務Fが定義されていたデータを削除すれば対応できるようになる。

以上述べたように、オペレータ業務の変更を、プログラム改修することなく、登録された操作ログに対する業務内容変更で対応できるよう構成したため、業務変更にかかる費用、時間を極小化する効果を得ることができる。

また、同様に理由で、既存システムへの組み込みも最低限の費用で実現できるようになる。

図１は、本実施形態であるシナリオ通知機能を示すブロック図である。

シナリオマスターメンテナンス部６０において、メンテナンス画面６３によってシナリオマスター６４を随時メンテナンスできることを可能とする。

また、ログ解析機能６１で、アプリケーション２１が出力する操作ログ内容を画面出力６２に出力し、シナリオマスター６４のシナリオ条件の内容設定に利用することを可能とする。

本発明は図１に示すとおり、任意のアプリケーション１０に存在する、操作ログ出力２１が出力した操作ログ２２を、操作ログ読取機能５１で読み取り、シナリオログ５２にデータを追加する。

この時、操作ログ２２がデータベースであった場合、図６のフローチャートにあるように、トリガー機能を利用する。操作ログにデータ追加があった場合S１１の通りデータベースシステムが検知する。同時に、登録済みSQLが動作するので（S１２）そのSQLで、シナリオログへの追加を定義しておく。

また、操作ログがシーケンシャルファイルの場合、この読取動作は、時間間隔指定で動作し、図７のフローチャートにあるように、ログ読取済データで操作ログを検索する（S２１）。このログ読取済データは、前回処理した操作ログの最終レコードと同一の値となる。フローチャートでは、S２８の処理にあたる。

検索できた場合、その検索レコードの次の位置から操作ログレコードを読み出す（S２３）。また、検索できない場合は、当該読取処理が1度も動作していないことなので、先頭レコードから読み出す（S２４）。

読み出した操作ログデータは、シナリオログへ無条件に追加する（S２５）。

操作ログの最終レコードまで処理したら、（S２５〜S２７）最終レコードを次回の読取位置として記憶する（S２８）。

図３は、操作ログがシーケンシャルファイルのときのシナリオログへのデータ複写例である。

この例では、ログ読取済データが操作ログ２２の２８番目のレコードと等価の場合、２９番目以降のデータがシナリオログ５１へ複写されることを表している。

図１の通り、操作ログ読取部５０が終了した時、シナリオ生成部７０が起動される。

シナリオ生成は、図８のフローチャートで示す。

シナリオマスター６４を先頭から読み込む（S３０）。シナリオマスター６４のシナリオ条件の内容で、シナリオログを検索するSQLを生成する（S３４）。この時、検索結果として読み込む内容は、キー指定１、２に指定されているキー項目と、日時とする。

検索できた場合、開始日付取得サブルーチン（S４０）に分岐する。開始日付取得サブルーチンは図９に示すとおり、シナリオマスター６４の開始日付取得SQLの内容でSQLを発行（S４１）し、検索できた場合（S４２）検索値を開始日付とする（S４４）。検索できなかった場合、S３４で読み込んだ日時を開始日付とする（S４３）。図４の出力例では、住所データ２３の登録日を検索することが示されている。の次に前記の開始日付に対して、シナリオマスター６４の開始日付計算方法による演算を実施する。開始日付計算方法は、演算子と数値の値で構成される（図４のシナリオマスター６４の内容を参照）ので、開始日付にその演算を実施する（S４５）。

次に、終了日付取得サブルーチン（S５０）に分岐する。終了日付取得サブルーチンは図１０に示すとおり、シナリオマスター６４の終了日付取得SQLの内容でSQLを発行（S５１）し、検索できた場合（S５２）検索値を終了日付とする（S５４）。図４の出力例では、住所データ２３の登録日を検索することが示されている。検索できなかった場合、S３４で読み込んだ日時を終了日付とする（S５３）。次に前記の終了日付に対して、シナリオマスター６４の終了日付計算方法による演算を実施する。終了日付計算方法は、演算子と数値の値で構成される（図４のシナリオマスター６４の内容を参照）ので、終了日付にその演算を実施する（S５５）。

次に、前記で取得した開始日付、終了日付、シナリオマスター６４の業務内容を用いて、シナリオマスター６４のシナリオ表示形式に則り、編集済み業務内容を作成する（S３８）。図１１に示すとおり、[と]で囲まれた、開始日付、終了日付には、前記で取得・計算した開始日付、終了日付の内容を当てはめる。同様に、[と]で囲まれた、業務内容には、シナリオマスター６４の業務内容の内容を当てはめる。

次に、前記までで取得した各データと、シナリオマスター６４の削除フラグを、シナリオデータ７２に記憶する（S３９）。

S３４で取得したキーカラム指定１，２の内容で、シナリオデータ７２を検索し、存在すれば、上書きし、存在しない場合は、データを追加する。

図４は、シナリオデータ７２のデータ割り当て例を示している。

シナリオマスター６４のシナリオ条件に、「画面名がMT001で、処理結果が更新のデータを検索せよ」という条件がセットされている時（J01）の、検索・データセット例を示している。

この時、シナリオログ５１が、シナリオ条件で検索できた場合、開始日付取得条件と終了日付取得条件がそれぞれ、「顧客番号が、シナリオログの顧客番号と同一の住所データを検索せよ」（J02）となっている。この条件で、住所データより開始日付と終了日付が取得できた場合の開始日付・終了日付演算方法が示されている（J03）。

シナリオデータ７２のシナリオIDは、シナリオマスター６４のシナリオIDをセットする。シナリオデータ７２のキー１は、シナリオログ５１の顧客番号がセットされる。

シナリオデータ７２のキー２は、この場合空白であるが、シナリオマスター６４のキー指定２が空白でない場合、該当するシナリオログ５１の内容がセットされることになる。シナリオデータ７２の開始日付は、前記で記述した取得・演算済みの開始日付がセットされる。シナリオデータ７２の終了日付も同様に、前記で記述した取得・演算済みの開始日付がセットされる。シナリオデータ７２の編集済み業務内容は、前記で示した（S３８）、編集済み業務内容がセットされる。

シナリオデータ７２の削除フラグは、シナリオマスター６４の削除フラグがセットされる。

ここで、一連の処理が終了し、アプリケーションからの要求を待つことになる。

アプリケーションからは、随時シナリオデータの要求が発行される。

図１に示すとおり、アプリケーション１０のシナリオを要求する、シナリオ取得３０が、APIであるアプリケーション呼出９０のシナリオ要求９１を発行することにより、シナリオ検索部８０が動作し、キー値に従って、シナリオデータ７２を検索しシナリオデータ７２の編集済み業務内容と削除フラグを渡すことになる。

図５に、シナリオ取得の具体例を示す。

ここでは、アプリケーションのシナリオ取得プログラムを「顧客情報画面（KK001）」としている（３１）。このプログラムが、顧客番号1001001のデータを表示するとき、その顧客に該当するシナリオを取得しようとしたとき、顧客番号（1001001）をAPIに渡して（J10）、シナリオデータ７２をシナリオデータ検索部８０が検索する。

データが存在したとき、シナリオデータ検索部８０は、受け渡されたキー（顧客番号）に該当する編集済み業務内容と削除フラグを渡す。

シナリオ取得（顧客情報画面）３１で削除フラグを受け取った場合、表示されているシナリオデータを削除する。

シナリオデータ削除は、アプリケーション側で過去に渡したシナリオ（編集済み業務内容）を保存している場合、その消去に利用できる。

本発明の実施の形態に係るシナリオ通知機能のシステムブロック図である。 本発明の実施の形態に係るシナリオ通知機能のアプリケションの操作ログ出力例である。 本発明の実施の形態に係るシナリオ通知機能のシナリオログへの複写である。 本発明の実施の形態に係るシナリオ通知機能のシナリオデータの出力例である。 本発明の実施の形態に係るシナリオ通知機能のシナリオ取得例である。」 本発明の実施の形態に係るシナリオ通知機能のシナリオログ追加のトリガー処理のフロー図である。 本発明の実施の形態に係るシナリオ通知機能のシナリオログ追加のシーケンシャルファイル処理のフロー図である。 本発明の実施の形態に係るシナリオ通知機能のシナリオ生成部の全体フロー図である。 本発明の実施の形態に係るシナリオ通知機能の開始日付取得サブルーケンのフロー図である。 本発明の実施の形態に係るシナリオ通知機能の終了日付取得サブルーケンのフロー図である。 シナリオ表示形式の説明図である。

符号の説明

１０…アプリケーション、２０…操作ログ出力、３０…シナリオ取得、４０…シナリオ通知機能、５０…操作ログ読取部、６０…シナリオメンテナンス部、７０…シナリオ生成部、８０…シナリオ検索部、９０…アプリケーション呼出。

Claims (6)

1. 特定のアプリケーションが出力する操作ログファイルより、操作内容から次業務と開始・終了日付を判定するシステムであって、
   操作ログを読み取り、シナリオログに登録し、操作ログをどのレコードまで処理したかを判定する操作ログ読み取り部と、
   操作ログ内容を業務内容と関連付けるデータと、開始日、終了日データを取得するSQLとその計算方法と、操作ログのどの部分をキー項目とするかを記憶できるシナリオマスターを保管し、メンテナンスできるシナリオメンテナンス部と、
   前記で登録されたシナリオマスターより、前記で登録されたシナリオログを検索し、業務内容と、開始日、終了日、きー値をシナリオデータに保持するシナリオ生成部と、
   アプリケーションAPIで提供される、キー値をインターフェースすることにより、前記シナリオデータを検索し、業務内容を返すシナリオ検索部で構成されるシナリオ通知機能。
2. 前記操作ログ読み取り部は、アプリケーション操作ログがどこまで読まれたかを記憶し、次に読込み要求があった場合、前回の読み取り位置以降で操作ログを読み取り、読み取られた操作ログは、シナリオログに記憶され、操作ログを直接使用しないことを特徴とする請求項１に記載のシナリオ通知機能。
3. 前記シナリオメンテナンス部は、操作ログ内容に対応する業務内容を記憶するエリアと、
   その業務内容の実施期間（開始日・終了日）の基点を取得するSQL文を記憶するエリアと、
   前記取得された開始日、終了日に対する計算方法（加減算）とその数値を記憶するエリアと、
   前記業務内容と、開始日、終了日の表示方法を記憶するエリアと、
   前記アプリケーション操作ログ内のどの項目をキー項目とするかを記憶するエリアと、
   既に登録されている業務内容を削除できる削除フラグを記憶するエリアをもつシナリオマスターをメンテナンスできることを特徴とする請求項１に記載のシナリオ通知機能。
4. 前記シナリオメンテナンス機能に付随の、操作ログと業務内容を結びつける目安として、操作ログ一覧を出力できる機能を特徴とする請求項１に記載のシナリオ通知機能。
5. 前記シナリオ生成部は、前記シナリオマスターより、シナリオログを読み、条件が合致した場合、シナリオマスターの開始日、終了日取得SQLを起動し、各基点日を算出し、その基点日に対し、各日付計算方法と数値により、日付計算を行い開始日と終了日を確定させる機能と、
   シナリオマスターに記憶されている業務内容と、前記で取得した開始日、終了日を、シナリオマスターに登録されている業務内容表示形式によって編集する機能と、
   シナリオマスターに登録されているキー項目より、キー値を取得する機能と、
   前記データを保持するシナリオデータを出力することを特徴とする請求項１に記載のシナリオ通知機能。
6. 前記シナリオ検索部は、API（アプリケーション・プログラム・インターフェース）で提供され、本システムに対してキー値を渡すことにより、そのキー値に合致したシナリオデータを検索し、編集済み業務内容を渡すことを特徴とする請求項１に記載のシナリオ通知機能。
   

Images