JP2010117899A - ジョブログ処理装置およびプログラム - Google Patents

Abstract

【課題】人事データベース等へのアクセスを制限しつつ、組織変更を反映し集計情報を取得し、かつ、異動情報が異動日より先行して人事データベースに登録されてしまう場合に対処する。
【解決手段】ユーザ異動履歴作成部１０２は、新たに収集したジョブログの範囲でユーザの所属部門が変更したかどうかを人事データベース１０７を参照して判断し、変更があったユーザについて、ユーザ識別情報、追加日、異動後の部門情報を含むユーザ異動履歴を生成し、ユーザ異動履歴記憶部１０５に記憶する。ジョブログ集計部１０３はジョブログ記憶部１０４のジョブログを、ユーザ異動履歴記憶部１０５のユーザ異動履歴を参照してユーザの所属部門に分類して所属部門ごとにジョブログを集計する。ジョブログ集計部１０３は、判定基準記憶部１０８の判定基準に基づいて、ユーザ異動履歴からはユーザの所属部門が決定不能であると判定された場合、このことを管理者に通知する。
【選択図】図１

Description

この発明は、ジョブログ処理装置およびプログラムに関する。

複写機、プリンタ等について、ジョブログを集計して課金単位の総量をユーザ単位、部門単位で管理することが行われている。例えば、図１に示すように、管理者等の計算機環境で実行される集計サービスＳが通信ネットワークを介して各デバイス（複写機、プリンタ等）からジョブログファイルＦを収集し、利用者情報Ｔを表引きして部門別の管理レポートＲを生成するようになっている。この例では集計対象は複写機等の面数である。

特許文献１は、部門コードは変更されず、部門名のみが変更された場合でも、部門名別のログ情報を認識でき、データサイズの低減化が図ることを提案している。この提案では、新規登録された部門情報を格納する部門テーブルと変更された部門情報を格納する部門変更テーブルがあり、これらのテーブル情報を用いて、ジョブログ出力時に、ジョブログ内の部門コードを部門名に置き換えて、出力させている。

特許文献２は、利用者ＩＤと部門ＩＤの対応付けのテーブルは用意して、利用者ＩＤを部門ＩＤに変換して、部門毎のコピー枚数を管理することを提案している。
特開２００４−３１８７０１号公報 特開２００５−２７１３１７号公報

この発明は、異動情報が実際の異動日より前にユーザの所属部門の情報として反映されてしまう場合に、ジョブを依頼したユーザと当該ユーザの所属情報との対応の不整合の可能性を通知できるジョブログ処理装置およびプログラムを提供することを目的としている。

請求項１の発明によれば、ジョブログ処理装置に：ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段と；収集した上記ジョブログを記憶するジョブログ記憶手段と；ユーザの所属部門の情報を記憶する所属情報記憶手段と；異動情報に基づいて、実際の異動日より先行して、上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段と；チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む日付、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段と；上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段と；上記ジョブログの各々について、当該ジョブログのユーザの識別子が示すユーザに関して作成された上記ユーザ異動履歴レコードのうちでジョブの実行時刻を含む日付が当該ジョブログの実行日と同日の１のユーザ異動履歴レコード、または当該ジョブログの実行日と直近において先行する１のユーザ異動履歴レコードを特定し、上記特定した１のユーザ異動履歴レコードの実行日が、上記実更新手段によりユーザの所属部門の情報の更新が行なわれた日から上記前記実際の異動日の前日までの期間に属さないとき、および、上記特定した１のユーザ異動履歴レコードの実行日が上記期間に属する場合であって予め定められた条件を満たすときに、当該ジョブログの集計対象情報を上記１のユーザ異動履歴レコードが示す所属部門に対応付ける手段と；上記特定した１のユーザ異動履歴レコードの実行日が、上記実更新手段により更新が行なわれた日から、上記前記実際の異動日の前日までの期間に属さない場合であって予め定められた条件を満たす場合に、予め定められた者に対して通知を行う通知手段とを設けている。
請求項２の発明によれば、請求項１のジョブログ処理装置において、上記予め定められた条件を、上記１のユーザ異動履歴レコードの実行日が、当該実行日より直近に先行する当該ユーザのジョブの実行日から予め定められた期間を経過した日ではないことにしている。
請求項３の発明によれば、コンピュータを：ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段；収集した上記ジョブログを記憶するジョブログ記憶手段；ユーザの所属部門の情報を記憶する所属情報記憶手段；異動情報に基づいて、実際の異動日より先行して、上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段；チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む日付、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段；上記ジョブログの各々について、当該ジョブログのユーザの識別子が示すユーザに関して作成された上記ユーザ異動履歴レコードのうちでジョブの実行時刻を含む日付が当該ジョブログの実行日と同日の１のユーザ異動履歴レコード、または当該ジョブログの実行日と直近において先行する１のユーザ異動履歴レコードを特定し、上記特定した１のユーザ異動履歴レコードの実行日が、上記実更新手段によりユーザの所属部門の情報の更新が行なわれた日から上記前記実際の異動日の前日までの期間に属さないとき、および、上記特定した１のユーザ異動履歴レコードの実行日が上記期間に属する場合であって予め定められた条件を満たすときに、当該ジョブログの集計対象情報を上記１のユーザ異動履歴レコードが示す所属部門に対応付ける手段；および、上記特定した１のユーザ異動履歴レコードの実行日が、上記実更新手段により更新が行なわれた日から、上記前記実際の異動日の前日までの期間に属さない場合であって予め定められた条件を満たす場合に、予め定められた者に対して通知を行う通知手段として機能させるジョブログ処理用プログラムを実現する。

請求項１または３の発明によれば、異動情報が実際の異動日より前にユーザの所属部門の情報として反映されてしまう場合に、ジョブを依頼したユーザと当該ユーザの所属情報との対応の不整合の可能性を通知できる。
請求項２の発明によれば、ジョブの実行間隔が予め定められた期間に満たない場合には、当該ジョブの実行を依頼したユーザの所属部門はその期間において変更されていないとみなした処理を行なえる。

以下、この発明の実施例について説明する。

図２は、この発明の実施例のジョブログ集計システム１００の計算機環境を全体として示しており、この例では、ジョブログ集計システム１００がサーバコンピュータ２０に実現されている。ジョブログ集計システム１００は複数のコンピュータを組み合わせて実現してもよい。ジョブログ集計システム１００は、サーバコンピュータ２０にジョブログ集計用のプログラム（他の補助的な機能を実現するプログラムモジュールを含んでもよい）を記録媒体２１や通信回線を用いてインストールして実現される。サーバコンピュータ２０は周知のＣＰＵ、主メモリ、バス、各種の入出力装置等を含んで構成され、サーバコンピュータ２０のハードウェア資源および記録媒体２１のプログラム等のソフトウェア資源が協働して以下に具体的に説明するジョブログ集計システム１００の各種機能ユニットを実現する。

図２において、任意個数の複写機１０Ａ〜１０Ｎ（単に「１０」と表す場合もある）、サーバコンピュータ２０、ホスト端末３０Ａ、３０Ｂ等が通信ネットワーク４０に接続されている。この例では複写機１０を示しているけれども、ファクシミリ装置、プリンタ、これらの装置の機能を併せ持つ複合機であってもよい。この例では、ジョブログ集計の対象は、画像形成の面数であるけれども、ジョブ要求に応じて消費される通信時間、使用時間、使用プログラム等の任意の資源を集計してもよい。なお、ジョブは、ユーザがデータ処理システムに対して要求する一まとまりの処理単位をいい、この例では、典型的には、１回のユーザ指示で実行される複写処理をいうが、これに限定されない。ジョブログは、ジョブの実行履歴をいい、典型的には、いつ、だれの要求に基づいて、どのような処理を要求したかを示すものであり、この例では、後に例示するように、ユーザ名、印刷時刻、集計対象の印刷面数等を含むがこれに限定されない。ここでは、１つのジョブログ、すなわち一まとまりの処理履歴に記録される処理単位がジョブとして扱われる。

複写機１０は、ユーザの要求したジョブを実行してそのジョブログを内部の記憶部に記憶保持している。ジョブログは、ユーザ識別情報、ジョブ実行時刻（どのような表示形態でも良い）、ジョブ量（面数）等を保持するが、これはジョブの内容に応じて変化する。複写機１０はジョブログ管理サービスを実行して、このジョブログ管理サービスが、後に説明するジョブログ集計システム１００のジョブログ収集部１０１と通信ネットワーク４０を介してやりとりを行い、ジョブログを収集部１０１に供給する。

ジョブログ集計システム１００は、ジョブログ収集部１０１、ユーザ異動履歴作成部１０２、ジョブログ集計部１０３、ジョブログ記憶部１０４、ユーザ異動履歴記憶部１０５、データベース管理部１０６、人事データベース１０７、判定基準記憶部１０８、判定基準設定部１０９、警告通知部１１０等を含んで構成される。ジョブログ収集部１０１は、複写機１０のジョブログ管理プログラムと協働して複写機１０に保持されているジョブログを収集してジョブログ記憶部１０４に記憶する。ジョブログの収集は典型的には定期的に行われる。ユーザ異動履歴作成部１０２は、新たに収集したジョブログの範囲でユーザの所属部門が変更したかどうかを人事データベース１０７を参照して判断し、変更があったユーザについて、ユーザ識別情報、追加日（ジョブ実行日）、異動後の部門情報（部門名、識別情報）を含むユーザ異動履歴（図４参照）を生成し、ユーザ異動履歴記憶部１０５に記憶する。ユーザ異動履歴作成部１０２の詳細な例は図５を参照して後に説明する。ジョブログ集計部１０３はジョブログ記憶部１０４のジョブログを、ユーザ異動履歴記憶部１０５のユーザ異動履歴を参照してユーザの所属部門に分類して所属部門ごとにジョブログを集計する。判定基準記憶部１０８は、どのようなユーザ移動履歴を参照してユーザの所属部門を決定するか、また、どのような場合にユーザの所属部門が決定不能であると決定するかを判定する判定基準を記憶する。判定基準設定部１０９はユーザからの判定基準入力に基づいて判定基準を判定基準記憶部１０８に記憶する。判定基準入力は典型的にはホスト端末３０Ａを介して行われるが、これに限定されない。集計部１０３におけるジョブログの集計動作は、このような判定基準に基づいて行われ、その詳細については図６を参照して後に詳述する。警告通知部１１０は、ユーザの所属部門が決定不能であると判定された場合に警告通知を行う。警告通知は、典型的には、集計処理に係る情報を記憶した動作ログに警告通知を出力して行うが、これに限定されず、例えば、電子メール等を用いてジョブログ集計管理者に送信してもよい。この例では、集計部１０３が、判定基準に基づいてユーザの所属部門が決定不能であると決定するけれども、他の機能ブロックで判定を行ってもよい。

管理部１０６は人事データベース１０７の更新を制御するように動作する。人事データベース１０７は、人事管理用の情報を保持するものであれけれども、この実施例との関係では、ユーザの所属する部門の情報、下位の部門が所属する上位の情報を保持する。通信ネットワーク４０を介してサーバコンピュータ２０（ジョブログ集計システム１００）に接続されたホスト端末３０Ｂを利用して人事データベース１０７の内容を異動情報に基づいて更新するよう指示できる。なお、この実施例では、実際の異動の前日に人事データベース１０７が更新されているものとする。前日の更新は、ユーザが直接に前日に更新指示を行ってもよいし、予め事前に指示を管理部１０６に供給しておくと管理部１０６が指示の前日に人事データベース１０７を更新するようにしてもよい。以下の例では、更新のタイミングは暦の上で予め定められているものとする。典型的には、月の初日に異動が行われ、更新が前月の末日に行われるけれども、これに限定されず、暦の上で予め定められ、システム上、既定のものであればどのようなものでもよい。週の初日、年の初め、年度の初めに異動が行われてもよい。

この実施例では、ジョブログは、ユーザを識別できる識別子（例：ユーザ名）と、印刷時刻、及び、集計に必要な面数情報などが記録される。印刷開始日（開始時刻）、印刷終了日（終了時刻）がある場合には、一方を印刷時刻、あるいは印刷日とする。典型的には、印刷終了日（終了時刻）を印刷日（時刻）として扱う。

人事データベース１０７の内容は、実際の異動日の前日（〆日ともいう）に変更される。ただし、これに限定されず、異動日の前日より前の予め定められたタイミングで人事データベース１０７の内容が変更されてもよい。

ユーザ異動履歴作成部１０２は人事データベース１０７を参照してユーザ異動履歴ファイルを作成し、これに基づいて部門別レポートを作成にする。ユーザ異動履歴は、ユーザを識別できる識別子（例：ユーザ名）、追加日（実行日が前日のジョブログに基づいて作成するので追加日は作成日の前日の日付）、最終印刷日、異動部門名（異動先部門名）を持つ。
典型的には、ユーザ異動履歴は日付変更時に毎日作成される（ユーザ異動履歴ファイルは毎日更新される）が、ユーザ異動履歴の作成を開始するタイミング（チェックポイントとも呼ぶ）は、その他種々採用可能である。例えば、ジョブが企業等の労働日またはシステムの稼働日しか生成されない場合には、労働日または稼働日の各々の次の日に変更された時を、ユーザ異動ファイルの作成開始のチェックポイントとして採用できる。また、日より短い単位または長い単位でチェックポイントの間隔を設定してもよい。以下では、チェックポイントとして、日付変更時を採用した場合について説明する。

ユーザ異動履歴から検出できないユーザの部門異動がある可能性がある場合がある。例えば、同一のユーザがＡ→Ｂ→Ｃと部門異動を行った場合に、部門Ｂで印刷を行わなかったときである。この際には、当該ユーザは部門Ｂに所属している間は印刷を行わなかったので、その間、当該ユーザに関してはユーザ異動履歴が作成されない。判定基準記憶部１０８の判定基準はこのような例外的な場合を判定するのにも用いる。そしてこのような判定がなされた場合には警告通知部１１０が通知を行う。

つぎに実施例の動作例を図３および図４をも参照して説明する。

この例では、ユーザを識別できる識別子（例：ユーザ名）と「印刷日」の情報を持つジョブログファイルと、ユーザの異動情報を持ったユーザ異動履歴ファイル（１以上のユーザ異動履歴を含むファイル）とを用いることにより、集計期間内のユーザの部門異動に対応した部門別集計レポートを作成する。ユーザ異動履歴作成部１０２は、人事データベース１０７から異動履歴ファイルを作成する。

また、組織変更（部門階層の変更）に対応できるように、「部門別日別集計レポート」を一時的に作成し、さらに、組織変更情報を用いることにより、集計期間内の組織変更に対応した上位部門別の集計レポートを作成する。

図３に示すように、ジョブログ収集サービス（ジョブログ収集部１０１）がジョブログを収集してジョブロブファイル（ジョブログ記憶部１０４）に保持する。ユーザ異動履歴作成サービス（ユーザ異動履歴作成部１０２）が作成日（当日）の前日のジョブログを参照して所属部門が前回参照時の部門と異なっているユーザについてユーザ識別情報、追加日（作成日の前日）、新しい所属部門の識別情報を含むユーザ異動履歴を作成してユーザ異動履歴ファイル（ユーザ異動履歴記憶部１０５）に保持する。ユーザ異動履歴ファイルは当該ユーザの最終印刷日も保持する。集計サービス（集計部１０３）はユーザ異動履歴ファイル１０５が示す異動情報に基づいてジョブログを部門ごとに集計する。集計サービスは警告通知判定基準（判定基準記憶部１０８の判定基準）を取得してユーザ異動履歴から検出できないユーザの部門異動がある可能性があると判定して警告通知サービス（警告通知部１１０）に通知を行わせる。

図４はジョブログの集計例を示している。この例では、ユーザ「ｔａｋａｏ」が２００７／０５／０１、２００７／１１／３０、２００８／０１／１０、および２００８／０２／２７にそれぞれ１０面、１０面、２０面および２０面の印刷をそれぞれ行っている。２００７／０５／０１の時点で、ユーザ「ｔａｋａｏ」は新たに部門Ａから部門Ｂに所属していたとすると、「ｔａｋａｏ：２００７／０５／０１：２００７／０５／０１：Ｂ部門」（ユーザ識別情報：追加日：最終印刷日：部門名）のユーザ異動履歴が生成され、さらにこのユーザ異動履歴の「最終印刷日」が、部門Ｂでの最終印刷日である２００７／１１／３０で更新書き込みされる。２００８／０１／１０の時点ではユーザ「ｔａｋａｏ」は部門Ｃに所属していたので、「ｔａｋａｏ：２００８／０１／１０：２００８／０１／１０（暫定）：Ｃ部門」の異動履歴が生成され、さらにこのユーザ異動履歴の「最終印刷日」が、に部門Ｃでの最終印刷日である２００８／０２／２７で更新書き込みされる。異動履歴とジョブログに基づいて「Ｂ部門：２０面」、「Ｃ部門：４０面」の部門別レポートが作成される。この例では簡略化して説明されているけれども、例えば、ユーザ「ｔａｋａｏ」は少なくとも２００７／０５／０１から２００７／１１／３０の間、Ｂ部門に所属しており、Ｂ部門の「ｔａｋａｏ」だけを考えると、Ｂ部門の２００７年の集計は１０面＋１０面の２０面となる。もちろん、Ｂ部門に他のメンバがいると、Ｂ部門の集計はもっと多くなる。同様にＣ部門の２００８年の集計は２０面＋２０面の４０面になる。上の例では、便宜上、年で集計する例を示したが、月、四半期等で集計してもよい。

つぎに、ユーザ異動履歴作成処理について図５を参照して説明する。

図５に示すようにユーザ異動履歴作成は以下のように行われる。

［ステップＳ１０］：前日分のジョブログに記録されている情報から前日にジョブを依頼したユーザのリスト（ユーザリスト）を作成する。
［ステップＳ１１］：ユーザリストに含まれるユーザの各々について以下の処理を行う。
（Ｓ１１ａ）ユーザ異動履歴ファイル内で、ユーザに対応する最新の部門名（Ｂ１)を取得する。
（Ｓ１１ｂ）人事データベース１０７からユーザの現在の所属部門名(Ｂ２)を取得しＢ１と比較する。
（Ｓ１１ｃ）異動履歴ファイルに対象ユーザのレコードがない場合、あるいは、Ｂ１とＢ２が異なる場合は、ユーザ、前日の日付、最終印刷日(前日の日付)、部門名（Ｂ２）のレコードを異動履歴ファイルに追加する。
（Ｓ１１ｄ）Ｂ１とＢ２が同じ場合は、最終印刷日(前日の日付)を更新する。

ユーザ異動履歴ファイルは以下に説明するジョブログの部門別集計に用いられる。

つぎにジョブログの部門別集計について図６を参照して説明する。

図６に示すようにジョブログの部門別集計は以下のように行われる。

［ステップＳ２０］：まず集計期間を指定する。これは任意のホスト端末またはサーバコンピュータ２０において指定できる。
［ステップＳ２１］：指定された範囲のジョブログの集合からを１ジョブ分の情報を読み込む。ジョブが残っている間、処理を繰り返す。指定期間内のジョブログがなければ、あるいは残っていなければ、この処理を抜けてステップＳ２３へ進む。そうでなければ、ステップＳ２２へ進む。
［ステップＳ２２］：ジョブログ内のユーザの情報および印刷日とユーザ異動履歴ファイルの情報とからユーザの所属部門を判定する。まず、異動履歴ファイルから対象ユーザのレコードを検索し、ジョブログにおける印刷日とユーザ異動履歴ファイルにおける追加日とを比較する。ここで、比較は検索されたレコードのうち追加日の古いものから順に行う。そして、印刷日が追加日以降の日付であれば、順次、当該ユーザの（印刷日における）所属部門を（ユーザ異動履歴ファイルの当該追加日に対応するレコードの）異動情報に基づき設定（更新）していく。そして、検索されたレコードすべてについて印刷日と比較し終え、あるいは、追加日が印刷日より後のレコードが見つかると、当該１つのジョブログについてユーザの所属部門の判定が終了してステップＳ２１に戻る。ただし、印刷日と同じ追加日のレコードがあり、その日が〆日の場合には、印刷日と、そのユーザの前の所属部門の最終印刷日を比較し、基準よりも間隔が短いときに、前の部門を所属部門と判別し（前の部門に集計し）、基準よりも間隔が長いときには、その旨警告を通知する。印刷日が追加日と異なる場合、または印刷日が追加日と同じでも〆日でない場合（上記以外の場合）には、印刷日と追加日の比較からユーザの所属部門を決定し、集計結果を更新する。
［ステップＳ２３］：判定した部門別でジョブログを集計して部門別集計レポートを作成する。

なお、上記では、人事データベース１０７の内容は、実際の異動日の前日（〆日）に変更されるものとしたが、人事データベース１０７の更新日は、実際の異動日の前日よりさらに前でもよい。その場合、当該更新日と実際の異動日の前日との期間（当該更新日と当該実際の異動日の前日とを含む）に、異動履歴ファイルの追加日が含まれる場合に、警告を通知するか否かの判断を行う。以下の説明でも同様である。

つぎに具体的な異動を例に挙げて実施例の動作をさらに説明する。

図７は二人のユーザＡおよびＢの異動の履歴を示す。図８はこのような異動履歴のユーザＡおよびＢのジョブの履歴を示す。図７の異動履歴をテーブルで表すと図９および図１０に示すようになる。ここでは、ユーザＡを２００６／４／１（２００６年４月１日）入社、ユーザＢを２００７／４／１入社で、どちらも、入社以来、２００８／０４／０１まではＯ部門に所属しているとする。

この例では、ユーザ異動履歴ファイルは図１１に示すようになる。ユーザＡについて検討すると、まず、システム運用開始後、初めて印刷を行った２００８／３／１５（２００８年３月１５日）を追加日、Ｏ部門というユーザ異動履歴が生成される。２００８／３／２０の印刷では同じくＯ部門であるのでユーザ異動履歴は追加されず、「２００８／３／２０」が、先のユーザ異動履歴の最終印刷日として更新書き込みされる。２００８／４／１０の印刷では、所属がＯ部門からＰ部門に変更されているので、２００８／４／１０を追加日、Ｐ部門というユーザ異動履歴が生成される。２００８／４／２０および２００８／５／１０の印刷では同じくＰ部門であるのでユーザ異動履歴は追加されず、「２００８／５／１０」が先のユーザ異動履歴の最終印刷日として更新書き込みされる。２００８／７／１０の印刷では、Ｐ部門からＲ部門に変更されているので、２００８／７／１０を追加日、Ｒ部門というユーザ異動履歴が生成される。このユーザ異動履歴の最終印刷日は暫定的に「２００８／７／１０」であり、ユーザＡがＲ部門に所属している間にさらに印刷を行った場合には、その印刷日で最終印刷日がさらに更新される。こうして図１１の上から１番目、２番目、５番目に示すようにユーザＡについてユーザ異動履歴が生成される。

同様にユーザＢについても図１１に示すようにユーザ異動履歴が生成される。ただし、ユーザＢの例では例外処理が行われている。すなわち、ジョブログの印刷日が異動履歴ファイルの追加日に等しくかつその日が〆日の場合、該当するユーザのひとつ前の部門の最終印刷日を検索する。上記の例では、２００８／５／３１のジョブログに対して、ユーザＢのひとつ前の部門（Ｐ部門）が該当し、最終印刷日として２００８／４／２０が検索される。次に、異動履歴ファイルに存在しない部門異動の可能性を判断するための判定基準の情報を判定基準記憶部１０８から取得する。この情報は運用環境に応じてユーザ（管理者）が設定部１０９により設定可能とする。例えば、この値が１ヶ月に設定されていた場合、印刷日の２００８／５／３１と最終印刷日２００８／４／２０の間が１ヶ月以上あるため、その間に部門異動があった可能性があると判断する。この場合には、その実績はＰ部門にはカウントされず、部門変更があった旨をユーザ（管理者）に通知する。具体的には集計時の警告通知を動作ログ等に残す。ユーザ（管理者）は動作ログからこれを識別して人事データベース１０７の詳細等を参照し、または確認作業を行って、手作業で集計に加算する。この例では、ユーザ（管理者）はその情報を元に、実際に部門異動があったかを判断し、手動で実際の部門（Ｑ部門）に累計する。通知は、典型的には、この例で示すように、動作ログに通知情報として含ませてもよいし、電子メール等のメッセージ送信手段で所定の宛て先に実際に送信されてもよい。もし、基準情報が２ヶ月に設定されている場合には、上記例においてはその実績値は自動的にＰ部門に計上されることになる。

異動履歴ファイルは、ジョブを印刷した日の部門で集計できることを目的で作成されたもので、完全に人事異動情報を作成するものではない。ユーザ異動履歴は、異動を反映する範囲で作成されていればよく、ジョブログすべてについて必要とされない。

つぎに上位階層の部門別集計レポートの作成について説明する。なお、企業、学校等の組織における木構造の階層において１のエンティティ（ノード）に対して他のエンティティが木構造をリーフ方向にたどれる場合に、１のエンティティを上位のエンティティと呼ぶ、他のエンティティを下位のエンティティと呼ぶ。上位または下位のエンティティは１つのリンク（エッジ）のみを介在させてもよく（直接的な上位または下位）、複数のリンクを介在させてもよい（間接的な上位または下位）。下位のエンティティから見て上位のエンティティを所属部門と呼ぶ。１のリンクを介する上位のエンティティを直接的な上位部門と呼び、複数のリンクを介する上位のエンティティを間接的な上位部門と呼ぶ。

組織階層が幾階層にもなっている場合でも、下位部門の集計結果を元データとして、組織変更履歴ファイルを用いて、再帰的に上位階層の部門レポートを作成することができ、最終的にある階層部門における月別の部門レポートを作成する。

すなわち、先に説明したようにユーザのジョブログからユーザが直接に所属する部門別の集計レポートを生成し、この集計レポートを図１２に示すように元データとして再帰的に上位の部門の集計レポートを生成できる。この場合、人事データベースは、部門が所属する上位の部門の異動情報（異動日、上位の部門の識別情報）を提供する。

図１３は、組織変更履歴（先の説明のユーザ異動履歴に対応する）を作成する処理を示しており、その詳細は以下のとおりである。

［ステップＳ３０］：異動履歴ファイルに新規追加されたユーザの部門のリストを作成する（典型的には、ユーザ異動履歴作成処理の後に実行する）。
［ステップＳ３１］：リストに含まれる部門ごとに以下の処理を行う。
（Ｓ３１ａ）組織変更履歴ファイル内で、下位部門に対応する最新の上位部門名（Ｂ１)を取得する。
（Ｓ３１ｂ）人事データベース１０７から下位部門の現在の上位部門名(Ｂ２)を取得し（Ｂ１）と比較する。
（Ｓ３１ｃ）組織変更履歴ファイルに対象部門のレコードがない場合、あるいは、Ｂ１とＢ２が異なる場合は、下位部門の識別情報、前日の日付（追加日）、上位部門の識別情報（Ｂ２）のレコードを組織変更履歴ファイルに追加する。
［ステップＳ３２］：処理結果（前日の更新処理済みフラグ）を更新（未処理→処理済みに変更する）する。

図１４は、上位の部門別にジョブログを集計する処理を示しており、その詳細は以下のとおりである。

［ステップＳ４０］：まず集計期間を指定する。これは任意のホスト端末またはサーバコンピュータ２０において指定できる。
［ステップＳ４１］：部門別、日別で集計レポートを作成する。
［ステップＳ４２］：指定された範囲の部門別、日別の集計レポートを１レコード読み込む。レコードが残っている間、処理を繰り返す。指定期間内のレコードがなければ、あるいは残っていなければ、この処理を抜けてステップＳ４４へ進む。そうでなければ、ステップＳ４３へ進む。
［ステップＳ４３］：１レコード分の集計レポート内の部門の情報および集計日の情報と、組織変更履歴ファイルの情報とから上位の部門を判定する。具体的には、組織変更履歴ファイルから対象部門のレコードを検索し、集計レポートにおける集計日と組織変更履歴ファイルにおける追加日とを比較する。ここで、比較は検索されたレコードのうち追加日の古いものから順に行う。そして集計日が追加日以降の日付である限り、順次、当該部門の（集計日における）上位の部門を（組織変更履歴ファイルの当該追加日に対応するレコードの）組織変更情報に基づき設定（更新）していく。そして、検索されたレコードすべてについて集計人比較し終え、あるいは、追加日が集計日よりあとのレコードが見つかると、ステップステップＳ４２に戻り、未処理の集計レポートから１レコード分読み込む。
［ステップＳ４４］：判定した上位部門別で、下位部門の集計レポートを集計して上位部門別集計レポートを作成する。

以上で実施例および変形例の説明を終了する。

なお、この発明は特許請求の範囲の記載に基づいて決定されるものであり、実施例の具体的な構成、課題、および効果には限定されない。この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。例えば、上述の例は、前のユーザ異動履歴から直前の異動部門を判定できるときには、手作業を経ることなく、その異動部門に累積するようにしたけれども、この場合にも、通知を行って、手作業で集計してもよい。また、複写機を例に挙げたが広くリソースの提供に適用可能である。また部門は企業内の部門に限定されず、広く組織のセクション、例えば大学の学部、学科等に適用できる。

従来例を説明する図である。 この発明の実施例のジョブログ集計システムおよびその利用環境を説明する図である。 上述実施例の動作例を全体として説明する図である。 上述の動作例をジョブログの例を挙げて説明する図である。 上述実施例のユーザ異動履歴作成処理の動作例を説明するフローチャートである。 上述実施例の部門別レポート作成処理の動作例を説明するフローチャートである。 上述実施例を具体例を用いて説明するための部門異動の例を示す図である。 上述実施例を具体例を用いて説明するための部門異動ならびに印刷履歴の例を示す図である。 上述実施例を具体例を用いて説明するためのユーザＡの部門異動の例を示す図である。 上述実施例を具体例を用いて説明するためのユーザＢの部門異動の例を示す図である。 上述実施例を具体例を用いて説明するための異動履歴ファイルの例を示す図である。 下位の部門別日別レポートから上位の部門別日別レポートを作成する動作例を説明する図である。 上位の部門別日別レポートを作成するための組織変更履歴を作成する動作例を説明するフローチャートである。 上位の部門別日別レポートを作成する動作例を説明するフローチャートである。

符号の説明

１０Ａ-１０Ｎ 複写機
２０ サーバコンピュータ
２１ 記録媒体
３０Ａ、３０Ｂ ホスト端末
４０ 通信ネットワーク
５０ サーバコンピュータ
１００ ジョブログ集計システム
１０１ ジョブログ収集部
１０２ ユーザ異動履歴作成部
１０３ ジョブログ集計部
１０４ ジョブログ記憶部
１０５ ユーザ異動履歴記憶部
１０６ データベース管理部
１０７ 人事データベース
１０８ 判定基準記憶部
１０９ 判定基準設定部
１１０ 警告通知部

Claims (3)

1. ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段と、
   収集した上記ジョブログを記憶するジョブログ記憶手段と、
   ユーザの所属部門の情報を記憶する所属情報記憶手段と、
   異動情報に基づいて、実際の異動日より先行して、上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段と、
   チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む日付、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段と、
   上記ジョブログの各々について、当該ジョブログのユーザの識別子が示すユーザに関して作成された上記ユーザ異動履歴レコードのうちでジョブの実行時刻を含む日付が当該ジョブログの実行日と同日の１のユーザ異動履歴レコード、または当該ジョブログの実行日と直近において先行する１のユーザ異動履歴レコードを特定し、上記特定した１のユーザ異動履歴レコードの実行日が、上記実更新手段によりユーザの所属部門の情報の更新が行なわれた日から上記前記実際の異動日の前日までの期間に属さないとき、および、上記特定した１のユーザ異動履歴レコードの実行日が上記期間に属する場合であって予め定められた条件を満たすときに、当該ジョブログの集計対象情報を上記１のユーザ異動履歴レコードが示す所属部門に対応付ける手段と、
   上記特定した１のユーザ異動履歴レコードの実行日が、上記更新手段により更新が行なわれた日から、上記前記実際の異動日の前日までの期間に属さない場合であって予め定められた条件を満たす場合に、予め定められた者に対して通知を行う通知手段と、
   を有するジョブログ処理装置。
2. 上記予め定められた条件は、上記１のユーザ異動履歴レコードの実行日が、当該実行日より直近に先行する当該ユーザのジョブの実行日から予め定められた期間を経過した日ではないことである請求項１に記載のジョブログ処理装置。
3. コンピュータを、
   ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段、
   収集した上記ジョブログを記憶するジョブログ記憶手段、
   ユーザの所属部門の情報を記憶する所属情報記憶手段、
   異動情報に基づいて、実際の異動日より先行して、上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段、
   チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む日付、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段、
   上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段、
   上記ジョブログの各々について、当該ジョブログのユーザの識別子が示すユーザに関して作成された上記ユーザ異動履歴レコードのうちでジョブの実行時刻を含む日付が当該ジョブログの実行日と同日の１のユーザ異動履歴レコード、または当該ジョブログの実行日と直近において先行する１のユーザ異動履歴レコードを特定し、上記特定した１のユーザ異動履歴レコードの実行日が、上記実更新手段によりユーザの所属部門の情報の更新が行なわれた日から上記前記実際の異動日の前日までの期間に属さないとき、および、上記特定した１のユーザ異動履歴レコードの実行日が上記期間に属する場合であって予め定められた条件を満たすときに、当該ジョブログの集計対象情報を上記１のユーザ異動履歴レコードが示す所属部門に対応付ける手段、および、
   上記特定した１のユーザ異動履歴レコードの実行日が、上記更新手段により更新が行なわれた日から、上記前記実際の異動日の前日までの期間に属さない場合であって予め定められた条件を満たす場合に、予め定められた者に対して通知を行う通知手段
   として機能させるためのジョブログ処理用プログラム。