JP2013246524A - 情報管理システム、情報管理方法及び情報管理プログラム - Google Patents

Abstract

【課題】異なる種類の情報を管理するとともに、種類の内容や種類数を変更する場合にも効率的に対応するための情報管理システム、情報管理方法及び情報管理プログラムを提供する。
【解決手段】個別情報記憶部２７には、管理ＩＤ、属種、属性に関するデータが記録される。承認管理サーバ２０の制御部２１は、クライアント端末１０から管理ＩＤを取得し、この処理に用いる画面データのプロパティにおいて、利用条件を確認する。そして、利用条件を満たす場合、画面に設定された属種に対する属性を個別情報記憶部２７から取得する。そして、この画面において属種が設定されたフィールドに、取得した属性を張りつけた表示画面を生成して、クライアント端末１０に出力する。また、この表示画面に属性が入力された場合、属性が入力されたフィールドに基づいて属種を特定し，属種と特性とを関連づけて、個別情報記憶部２７に登録する。
【選択図】図１

Description

本発明は、異なる種類の情報を管理するための情報管理システム、情報管理方法及び情報管理プログラムに関する。

企業等において、各種情報を管理するためのシステムが構築されている。例えば、申請等を管理するための作業申請管理システムが検討されている（例えば、特許文献１参照）。この文献に記載された作業申請管理システムにおいては、承認管理サーバの制御部は、申請処理において、クライアント端末から作業内容を取得した場合、申請雛形情報記憶部において申請書の雛形を検索する。そして、制御部は、申請書の雛形をクライアント端末に提供する。また、作業実績確認処理において、制御部は、作業実績と作業申請との不整合の有無を判定する。不整合がある場合には、申請者や作業者に注意を喚起する。作業後処理において、作業結果の承認申請を取得した場合、制御部は、作業結果と申請内容とを比較する。そして、内容が一致していない場合、差分補完処理として、元の申請の修正処理、追加作業申請処理のいずれかを実行する。

また、レコードを構成する項目の種類をユーザが容易に追加・変更するためのデータ管理システムが検討されている（例えば、特許文献２参照）。この文献に記載された作業申請管理システムにおいては、レコードの項目を入力するための入力画面に、固定的な項目名の入力フィールドだけでなく、ユーザが自由に項目名を設定できる自由入力フィールドを設ける。数値入力用の自由入力フィールドと文字入力用の自由入力フィールドとがセットである。自由入力フィールドに対しユーザが設定した項目名は、システム内の記憶装置上のユーザ項目名テーブルに登録される。入力画面を開くとき、ユーザ項目名テーブルからユーザ項目名が読み込まれて、入力画面の対応する自由入力フィールドの横に項目名として表示される。入力画面に入力された諸項目のデータは、レコードとして記憶装置に登録される。

特開２０１１−２１５７２６号公報（第１頁、図１） 特開平１０−３４０３０４号公報（第１頁、図１）

上述した特許文献１に記載されているように、情報管理においては、複数の項目についての情報を一つのレコードにまとめて管理することが多い。一つのレコードにまとめると、情報の検索や情報容量を小さくする点では効率的である。しかしながら、作業において新たな項目を追加する場合には、各レコードのデータ構成を作り直す必要があり、システム構成の変更が困難である。例えば、企業状況や外部環境に応じて、業務管理における業務要件が変更されることがある。この場合、企業内で業務管理を行なうためのワークフロー管理システムにおいて、業務要件の変更に伴うカスタマイズが必要になる。このカスタマイズを迅速に行なうためにユーザ側で実施する場合には、ユーザフレンドリーなユーザインターフェイスにより、効率的かつ柔軟に対応できるシステム構成が望ましい。

また、特許文献２に記載されている技術においては、項目の種類を追加や変更することができる。しかしながら、この場合においても、予めレコードにおいて準備されたフィールド数の範囲でしか対応することができず、変更の自由度に制限がある。

本発明は、上記課題を解決するためになされたものであり、異なる種類の情報を管理するとともに、種類の内容や種類数を変更する場合にも効率的に対応するための情報管理システム、情報管理方法及び情報管理プログラムを提供することにある。

上記問題点を解決するために、請求項１に記載の発明は、管理識別子に対して、属種及び属性が関連付けられた個別管理データを記憶する個別情報記憶部と、クライアント端末に接続された制御部とを備えた情報管理システムであって、前記制御部が、クライアント端末の入力画面において入力された属性について属種を特定し、属種及び属性に関する情報を取得し、前記取得した属種及び属性に関する情報に対して管理識別子を特定し、前記管理識別子に関連付けて属種及び属性を記録した個別管理データを生成して前記個別情報記憶部に記録し、クライアント端末に表示画面を出力する場合には、前記表示画面の管理識別子に関連付けられ、前記表示画面に含まれる属種に対応する属性を前記個別情報記憶部から取得し、前記属性を前記属種に対応させて設定した表示画面を生成し、前記クライアント端末に出力することを要旨とする。

請求項２に記載の発明は、請求項１に記載の情報管理システムにおいて、入力画面を作成するための作業画面を出力する設定管理手段を備え、前記設定管理手段が、前記作業画面において、管理識別子に関連付けられた入力画面のレイアウトを設定するとともに、前記レイアウトに含まれる入力欄に対して属種を関連づけて記録することにより、前記入力画面において入力された属性の属種を特定することを要旨とする。

請求項３に記載の発明は、請求項１又は２に記載の情報管理システムにおいて、前記入力画面は、複数の業務ステップから構成された業務プロセスの一部の業務ステップにおいて、属性を入力するための画面であり、前記管理識別子は、前記業務プロセス及び業務ステップを特定するための情報から構成されていることを要旨とする。

請求項４に記載の発明は、請求項１〜３のいずれか一つに記載の情報管理システムにおいて、前記制御部は、データ入力に用いる、ワークシートとフォーマットシートとからなる表計算ファイルを取得し、前記フォーマットシートの各フィールドに記録された属種を特定し、前記ワークシートにおいて、前記フォーマットシートの属種が記録されたフィールドの位置に対応するフィールドから属性を取得し、前記個別情報記憶部に記録することを要旨とする。

請求項５に記載の発明は、請求項１〜４のいずれか一つに記載の情報管理システムにおいて、前記制御部は、データ出力に用いる、ワークシートとフォーマットシートとからなる表計算ファイルを特定し、前記フォーマットシートの各フィールドに記録された属種を特定し、前記個別情報記憶部から、前記特定した属種に対応する属性を抽出し、前記ワークシートにおいて、フォーマットシートに記録された属種のフィールドの位置に対応するフィールドに前記属性を設定することにより、出力帳票を作成することを要旨とする。

請求項６に記載の発明は、管理識別子に対して、属種及び属性が関連付けられた個別管理データを記憶する個別情報記憶部と、クライアント端末に接続された制御部とを備えた情報管理システムを用いて、情報を管理するための方法であって、前記制御部が、クライアント端末の入力画面において入力された属性について属種を特定し、属種及び属性に関する情報を取得し、前記取得した属種及び属性に関する情報に対して管理識別子を特定し、前記管理識別子に関連付けて属種及び属性を記録した個別管理データを生成して前記個別情報記憶部に記録し、クライアント端末に表示画面を出力する場合には、前記表示画面の管理識別子に関連付けられ、前記表示画面に含まれる属種に対応する属性を前記個別情報記憶部から取得し、前記属性を前記属種に対応させて設定した表示画面を生成し、前記クライアント端末に出力することを要旨とする。

請求項７に記載の発明は、管理識別子に対して、属種及び属性が関連付けられた個別管理データを記憶する個別情報記憶部と、クライアント端末に接続された制御部とを備えた情報管理システムを用いて、情報を管理するためのプログラムであって、前記制御部を、クライアント端末の入力画面において入力された属性について属種を特定し、属種及び属性に関する情報を取得し、前記取得した属種及び属性に関する情報に対して管理識別子を特定し、前記管理識別子に関連付けて属種及び属性を記録した個別管理データを生成して前記個別情報記憶部に記録し、クライアント端末に表示画面を出力する場合には、前記表示画面の管理識別子に関連付けられ、前記表示画面に含まれる属種に対応する属性を前記個別情報記憶部から取得し、前記属性を前記属種に対応させて設定した表示画面を生成し、前記クライアント端末に出力する手段として機能させることを要旨とする。

（作用）
請求項１、６又は７に記載の発明によれば、制御部が、クライアント端末の入力画面において入力された属性について属種を特定し、属種及び属性に関する情報を取得し、取得した属種及び属性に関する情報に対して管理識別子を特定し、管理識別子に関連付けて属種及び属性を記録した個別管理データを生成して個別情報記憶部に記録する。そして、クライアント端末に表示画面を出力する場合には、表示画面の管理識別子に関連付けられ、表示画面に含まれる属種に対応する属性を個別情報記憶部から取得し、属性を属種に対応させて設定した表示画面を生成し、クライアント端末に出力する。これにより、入力画面において、属種に対応した属性を取得し、表示画面において、属種に対応した属性を出力することができる。入力されたデータをまとめて個別管理データにおいて管理する場合と異なり、入力や出力に用いる項目（属種）を追加や変更の自由度を高くすることができる。

請求項２に記載の発明によれば、設定管理手段が、作業画面において、管理識別子に関連付けられた入力画面のレイアウトを設定するとともに、レイアウトに含まれる入力欄に対して属種を関連づけて記録することにより、入力画面において入力された属性の属種を特定する。これにより、作業画面を用いることにより、入力画面を作成することができる。

請求項３に記載の発明によれば、管理識別子は、業務プロセス及び業務ステップを特定するための情報から構成されている。これにより、複数の業務ステップからなる業務プロセスにおいて用いる情報を効率的に管理することができる。

請求項４に記載の発明によれば、データ入力に用いる、ワークシートとフォーマットシートとからなる表計算ファイルを取得し、フォーマットシートの各フィールドに記録された属種を特定し、ワークシートにおいて、フォーマットシートの属種が記録されたフィールドの位置に対応するフィールドから属性を取得し、個別情報記憶部に記録する。これにより、表計算ファイルを用いて、情報入力を行なうことができる。

請求項５に記載の発明によれば、データ出力に用いる、ワークシートとフォーマットシートとからなる表計算ファイルを特定し、フォーマットシートの各フィールドに記録された属種を特定し、個別情報記憶部から、特定した属種に対応する属性を抽出し、ワークシートにおいて、フォーマットシートに記録された属種のフィールドの位置に対応するフィールドに属性を設定することにより、出力帳票を作成する。これにより、表計算ファイルを用いて、情報出力を行なうことができる。

本発明によれば、異なる種類の情報を管理するとともに、種類の内容や種類数を変更する場合にも効率的に対応するための情報管理システム、情報管理方法及び情報管理プログラムを提供することができる。

本発明の実施形態のシステム概略図。 本実施形態の業務プロセスと業務ステップとの関係の説明図。 本実施形態のドキュメント状態の説明図。 本実施形態の業務プロセスの具体例の説明図であって、（ａ）は重大な不適合に対する業務プロセス、（ｂ）は軽微な不適合に対する業務プロセスの説明図。 本実施形態で用いるデータの説明図であって、（ａ）は設定情報記憶部、（ｂ）はユーザ記憶部、（ｃ）は業務プロセス記憶部、（ｄ）は回付ルート記憶部に記録されたデータの説明図。 本実施形態の画面遷移の説明図。 本実施形態で用いるデータの説明図であって、画面記憶部、個別情報記憶部、テンプレートファイルに記録されたデータの説明図。 本実施形態の処理手順の説明図。 本実施形態で用いる画面の説明図であって、（ａ）は初期設定画面、（ｂ）はユーザ登録画面、（ｃ）は回付ルート登録画面の説明図。 本実施形態で用いる詳細作業画面、ドキュメント登録画面の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。

以下、本発明を具体化した一実施形態を、図１〜図１５に従って説明する。本実施形態では、申請者が提出した申請について、承認者が行なう承認を支援するための承認管理システム、承認管理方法及び承認管理プログラムとして説明する。

本実施形態では、図１に示すように、申請の承認管理を支援するために、承認管理システムとしての承認管理サーバ２０を用いる。この承認管理サーバ２０は、ネットワークを介して、クライアント端末１０やディレクトリ管理サーバ４０に接続される。

本実施形態では、図２に示すように、一つの申請（ジョブ）に対して、一つの業務プロセスを用いて承認が行なわれる。この業務プロセスは、複数の業務ステップ（１〜ｎ）から構成されている。各業務ステップにおいては、回付ルートにおいて定められた部署、役職、個人への回付（連絡や承認）が行なわれる。各業務ステップにおいて必須の承認を完了した場合には、次の業務ステップにおいて回付（連絡や承認）が行なわれる。そして、業務ステップにおける最終承認を終了した場合に回付を終了する。

各業務ステップにおいては、回付に用いるドキュメントを生成する。本実施形態では、後述するように、ドキュメントに含まれる項目（属種）に対して値（属性）を設定することにより、ドキュメントを生成する。ここで、図３は、ドキュメントの状態を示している。ドキュメントを最初に作成した場合、「作成中」の状態となる。ドキュメントの作成を完了し、回付開始が入力されると「回付中」の状態となる。この場合、予め定められた回付ルートに基づいて、申請やドキュメントの回付が行なわれる。そして、「回付中」のドキュメントを承認処理により否認すると、「否認」の状態となる。また、「回付中」のドキュメントをキャンセルすると「回付取消」の状態となる。「回付中」のドキュメントについて、すべての承認者の承認が行なわれると「完了」の状態となる。

承認管理方法の具体例を、図４を用いて説明する。この図４では、不適合報告に対する対応を示している。図４（ａ）は、重大な不適合に対する業務プロセスであり、図４（ｂ）は軽微な不適合に対する業務プロセスを示している。

営業部において重大な不適合についての申請を行なう場合、３つの業務ステップ（不適合報告ステップ、不適合対応ステップ、不適合防止ステップ）から構成された業務プロセスが実行される。まず、不適合報告ステップにおいては、重大な不適合についての申請についてのジョブ、製品状況ファイルを添付した不適合報告についてのドキュメントを作成して回付を開始する。この不適合報告のドキュメントは、回付ルートに基づいて、製造部及び品質管理部に連絡される。この連絡完了を条件として、次の業務ステップである不適合対応ステップに移行する。ここでは、製造部において、不適合の原因や修理を記載した原因修理ファイルを添付した不適合対応についてのドキュメントを作成して回付を開始する。このドキュメントは、回付ルートに基づいて、品質管理部において回付されて内容確認が行なわれる。品質管理部における承認が完了した場合、回付ルートに基づいて、営業部に配布される。更に、品質管理部の承認を条件として、次の業務ステップである不適合防止ステップに移行する。この場合には、製造部において、不適合防止のために予防策を記載した予防策ファイルを添付した不適合防止についてのドキュメントを作成して、回付を開始する。この予防策のドキュメントは、回付ルートに基づいて、品質管理部において承認される。品質管理部における承認の完了により、重大な不適合の業務プロセスを終了する。

一方、営業部において軽微な不適合についての申請を行なう場合、２つの業務ステップ（不適合報告ステップ、不適合対応ステップ）から構成された業務プロセスが実行される。まず、不適合報告ステップにおいては、軽微な不適合についての申請についてのジョブ、不適合報告についてのドキュメントを作成して回付を開始する。なお、ここでは、ファイルは添付されず、回付されたドキュメント（申請内容）により連絡や承認が行なわれる。この場合にも、不適合報告のドキュメントは、回付ルートに基づいて、製造部及び品質管理部に連絡される。製造部への連絡を条件として、次の業務ステップである不適合対応ステップに移行する。ここでは、製造部において、不適合の原因や修理を記載した不適合対応についてのドキュメントを作成して、回付を開始する。この不適合対応は、品質管理部において回付されて内容確認が行なわれる。品質管理部における承認を条件として、営業部に配布される。営業部への配布により、軽微な不適合の業務プロセスを終了する。

このように、部分的に共通する複数の業務ステップを組み合わせて、目的に応じて２つの業務プロセスを構成することができる。
次に、承認管理システムの構成を説明する。
クライアント端末１０は、承認管理サーバ２０の管理者、申請者や、承認者等の回付先のユーザが用いるコンピュータ端末である。承認管理サーバ２０の管理者は、クライアント端末１０を用いて、承認管理サーバ２０における初期設定やユーザ登録、回付ルートの登録等を行なう。申請者は、クライアント端末１０を用いて、各種申請を行なう。承認者や確認者等の回付先のユーザは、クライアント端末１０を用いて、申請内容を確認する。そして、承認者は、ドキュメントの内容を確認して、承認や否認、キャンセルの入力等を行なう。このクライアント端末１０は、図示しないディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。

ディレクトリ管理サーバ４０は、ネットワーク上の資源とその属性とに関する情報を記憶し、検索できるようにしたディレクトリサービスを提供するコンピュータシステムである。このディレクトリ管理サーバ４０は、ユーザやネットワーク資源の管理を一括して行なう。このため、ネットワークを利用するユーザや組織に関する情報を蓄積したユーザデータベースを備えている。

ユーザデータベースには、承認管理サーバ２０を利用するユーザを管理するためのユーザ管理レコードが記録されている。このユーザ管理レコードは、ユーザ登録が行なわれた場合に記録される。ユーザ管理レコードには、従業員コード、氏名、連絡先、所属、役職、認証コードに関するデータが記録されている。

従業員コードデータ領域には、各従業員を特定するための識別子（例えば、社員番号）に関するデータが記録される。
氏名データ領域には、このユーザの氏名に関するデータが記録される。
連絡先データ領域には、このユーザの連絡先（例えば、メールアドレスや電話番号）に関するデータが記録される。

所属データ領域には、このユーザが所属する部署を特定するための識別子に関するデータが記録される。
役職データ領域には、このユーザの役職を特定するための識別子に関するデータが記録される。この役職により、承認の権限を特定することができる。
認証コードデータ領域には、ユーザ認証を行なう場合の認証情報（例えば、パスワード）に関するデータが記録される。

承認管理サーバ２０は、申請者に登録された申請（ジョブ）の承認を管理するためのサーバコンピュータである。この承認管理サーバ２０は、図１に示すように、制御部２１、設定情報記憶部２２、ユーザ記憶部２３、業務プロセス記憶部２４、回付ルート記憶部２５、画面記憶部２６、個別情報記憶部２７を備えている。

ここで、制御部２１は、ＣＰＵ、ＲＡＭ、ＲＯＭ（図示せず）等から構成された制御手段を備えており、後述する処理（設定管理段階、ユーザ認証段階、画面制御段階、申請管理段階、承認管理段階等の各処理）を行なう。そして、制御部２１は、図１に示すように、承認管理プログラムの実行により、設定管理手段２１１、ユーザ認証手段２１２、画面制御手段２１３、申請管理手段２１４、承認管理手段２１５として機能する。

設定管理手段２１１は、承認管理サーバ２０を利用するための初期設定、ユーザ登録、回付ルート登録のための設定情報の登録処理を実行する。
ユーザ認証手段２１２は、クライアント端末１０のユーザを認証する処理を実行する。このユーザ認証手段２１２は、クライアント端末１０から、ユーザの認証情報（従業員コード及び認証コード）を取得する。更に、ユーザ認証手段２１２は、ディレクトリ管理サーバ４０を用いて、アクセスしたユーザを特定する。ユーザ認証ができなかった場合には、エラーメッセージをクライアント端末１０に送信する。ユーザ認証ができた場合には、承認管理サーバ２０の利用を許可する。

画面制御手段２１３は、申請や承認を行なうための各種画面をクライアント端末１０に提供するとともに、クライアント端末１０において各種画面に入力された情報を取得する処理を実行する。
申請管理手段２１４は、申請者による申請を管理する処理を実行する。
承認管理手段２１５は、承認者による承認を管理する処理を実行する。

また、制御部２１は、承認者の役職に対応させて、承認を行なうまでの猶予期間（日数）を定めた猶予期間テーブル（猶予期間記憶部）を保持している。この猶予期間テーブルを用いることにより、各承認者の役職に対応して、現在日付及び猶予期間から承認期限を算出することができる。

設定情報記憶部２２には、図５（ａ）に示すように、承認管理サーバ２０を用いるための初期設定情報ファイル２２０が記録される。この初期設定情報ファイル２２０は、承認管理サーバ２０の管理者によって初期設定が行なわれた場合に登録される。初期設定情報ファイル２２０には、業務プロセス設定、台帳設定、メニュー設定、システム定義設定、画面定義設定、ラベル設定、メッセージ設定、メール設定に関する情報が記録される。

業務プロセス設定情報においては、業務プロセスの名称、業務プロセスの説明、自動採番方式（初期番号や採番ルール）、業務プロセスに含まれる業務ステップ（ステップＩＤ）に関する情報が記録される。

台帳設定情報においては、ユーザに提供する各種台帳のフォーマット（台帳に表示する項目等）や、台帳を表示させるユーザ等に関するデータが記録される。
メニュー設定情報においては、ユーザがアクセスした時のメニュー画面に含める項目に関するデータが記録される。

システム定義設定情報においては、承認管理サーバ２０の動作環境についての設定情報が記録される。例えば、承認管理サーバ２０のドメイン設定、パスワード条件（有効期限やパスワード長）、ディレクトリ設定等を行なうことができる。

画面定義設定情報においては、各画面を制御するための設定情報が記録される。例えば、回付ルート登録画面において設定された回付ルートの自動採番方式や、自動採番の最小値、デフォルト値等を設定する。また、承認画面においては、一度で複数件の承認を行なう複数承認の可否等を設定する。

ラベル設定情報においては、各画面において固定配置されるラベルに関するデータが記録される。
メッセージ設定情報においては、処理実行時のサクセスメッセージやエラーメッセージが記録される。

メール設定情報においては、回付開始や承認時等に送信するメールの送信内容に関するデータが記録される。具体的には、メールを送信するステップの指定（ステップ指定）、メール種別、題名、本文等を設定することができる。

ユーザ記憶部２３には、図５（ｂ）に示すように、承認管理サーバ２０のユーザを管理するためのユーザ管理レコード２３０が記録される。このユーザ管理レコード２３０は、管理者によってユーザ登録された場合に記録される。ユーザ管理レコード２３０には、従業員ＩＤ、メールアドレス、管理者、姓名（漢字）、所属（１）〜所属（ｎ）、役職、役職所属、権限グループに関するデータを含んで構成される。

従業員ＩＤデータ領域には、各ユーザを特定するための識別子に関するデータが記録される。
メールアドレスデータ領域には、このユーザが用いている連絡先（メールアドレス）に関するデータが記録される。

管理者データ領域には、管理者権限の有無を特定するためのフラグが記録される。
姓名（漢字）データ領域には、このユーザの氏名の漢字表記に関するデータが記録される。

所属（１）〜所属（ｎ）データ領域には、このユーザの所属に関するデータが記録される。本実施形態では、各データ領域に上位組織から下位組織の順番に組織名称が記録される。「所属（１）」には部名（例えば「製造部」）、「所属（２）」には、この部に属するチーム名（例えば「第１チーム」）、「所属（３）」には、このチームに属する課名（例えば「第２課」）等が記録される。

役職データ領域には、このユーザの役職に関するデータが記録される。例えば、役職としては、「部長」、「チーム長」、「課長」等を用いる。なお、役職がない場合には、このデータ領域を空欄にする。

役職所属データ領域には、ユーザの役職が与えられた所属を特定するための識別子に関するデータが記録される。例えば、「部長」の場合には「所属（１）」、「チーム長」の場合には「所属（２）」、「課長」の場合には「所属（３）」のように、それぞれ設定される。

権限グループデータ領域には、このユーザにおける、承認管理サーバ２０の利用権限を特定するための識別子に関するデータが記録される。例えば、特定の台帳についての閲覧権限等が設定される。

業務プロセス記憶部２４には、図５（ｃ）に示すように、業務プロセスを構成する業務ステップを管理するための業務プロセス管理レコード２４０が記録される。この業務プロセス管理レコード２４０は、初期設定時に登録される。業務プロセス管理レコード２４０は、業務ＩＤ、説明、ステップＩＤ（１）〜（ｎ）に関するデータを含んで構成される。

業務ＩＤデータ領域には、この業務プロセスを特定するための識別子に関するデータが記録される。
説明データ領域には、この業務プロセスの内容についての説明が記録される。例えば、「重大な不適合のワークフロー」、「軽微な不適合のワークフロー」等の説明を用いる。

ステップＩＤデータ領域には、この業務プロセスを構成する業務ステップを特定するための識別子に関するデータが記録される。複数の業務ステップから構成される場合には、すべての業務ステップを特定するためのステップＩＤが、実行順に記録される。

回付ルート記憶部２５には、図５（ｄ）に示すように、登録されたジョブについてのドキュメントを回付させるための回付ルートを記録した回付ルート管理レコード２５０が記録される。この回付ルート管理レコード２５０は、管理者によって回付ルートが登録された場合に記録される。回付ルート管理レコード２５０には、ルートＩＤ、業務ＩＤ、ステップＩＤ、登録者に関連付けられて、回付先情報（回付区分、必須・任意指定、従業員名称、グループ名、所属、職位）に関するデータを含んで構成される。なお、一つの業務プロセス、業務ステップにおいて、複数の回付先を登録することができる。

ルートＩＤデータ領域には、この回付ルートを特定するための識別子に関するデータが記録される。
業務ＩＤ、ステップＩＤデータ領域には、この回付ルートを適用する業務プロセスや業務ステップを特定するための識別子に関するデータが記録される。
登録者データ領域には、この回付ルートを登録した従業員に関するデータが記録される。

回付区分データ領域には、回付先における作業を特定するためのデータが記録される。本実施形態においては、「連絡」、「承認（１）」、「承認（２）」…、「配布」のいずれかが記録される。ここで、「連絡」は回付開始時に登録内容をメールで通知する回付先を示す。「承認（１）」は、回付開始時に、最初に承認を行なう回付先を示す。また、「承認（ｉ）」は、「承認（ｉ−１）」、「必須」で設定されたすべての承認者の承認を完了した場合に、承認を行なう回付先を示す。「配布」は、すべての承認者の承認を完了した場合に、ジョブについてのドキュメントを配布する回付先を示す。

必須・任意指定データ領域には、回付先における作業（例えば、承認作業）について必須又は任意を識別するための区分である。
従業員名称データ領域には、回付区分において指定された作業を行なう回付先（ユーザ）を特定するための識別子が記録される。ここでは、部署や役職、従業員名を用いて、回付対象のユーザを特定することができる。

グループ名データ領域には、回付先のユーザが属するグループを特定するための識別子が記録される。
所属データ領域には、回付先のユーザが所属する部署を特定するためのデータが記録される。
職位データ領域には、回付先のユーザの職位に関するデータが記録される。

画面記憶部２６には、図６に示すように、承認管理サーバ２０の利用時に使用する画面データが記録される。この画面データは、ユーザ（管理者）によって、画面レイアウトが決定された場合に登録される。画面記憶部２６には、図６に示すように、トップ画面６１０、ドキュメント登録画面６１１、回付開始画面６１２、台帳画面６１３、承認画面６１４、取り戻し画面６１５、回付進捗詳細画面６１６、承認者変更画面６１７等が記録される。

トップ画面６１０は、ユーザ認証を完了した場合に最初に表示される画面である。このトップ画面６１０には、メニュー定義において設定された内容（例えば、「作業待ち」、「作業選択」、「お知らせ表示」等）の各表示欄が含まれる。

ドキュメント登録画面６１１は、申請のためのジョブやドキュメントを登録する画面である。この画面は、後述する詳細作業画面において設定された内容が表示される。ドキュメント登録画面６１１においては、ジョブＩＤ、ドキュメントＩＤに関連付けられて、属種（項目）に対応して入力される属性（値）を設定することができる。

回付開始画面６１２においては、ドキュメント登録画面６１１を用いて作成された申請（ジョブ）の回付ルートが表示される。そして、このジョブについての回付開始や回付キャンセルを入力することができる。

台帳画面６１３においては、登録されているジョブやドキュメントを一覧表示させた台帳が表示される。
承認画面６１４は、承認者が申請内容を確認して、承認可否を入力するための画面である。この承認画面６１４には、承認又は否認を入力するためのアイコンが含まれる。更に、承認時におけるコメント入力欄も含まれる。

取り戻し画面６１５は、申請者が、回付開始された申請（ジョブ）を取り戻すための画面である。この画面において、取り戻しの要否を入力する。
回付進捗詳細画面６１６においては、指定された申請（ジョブ）について、回付ルートにおける進捗状況が表示される。この回付進捗詳細画面６１６には、回付区分、必須・任意指定、氏名（作成者又は承認者）、部署（作成者又は承認者の所属）、承認日（承認済みの場合のみ）、承認時のコメントの各表示欄が含まれる。

承認者変更画面６１７は、初期設定の承認者を変更するための画面である。例えば、本来の承認者において、承認入力が困難な場合に、他のユーザを、所定の条件の下に承認者として設定することができる。なお、自己決裁禁止機能により、申請者自身を決裁権限者とする承認ルートを禁止する。具体的には、回付開始画面の「回付開始」を押下した時、回付ルートの最終承認者がログインユーザである場合はエラーにする。

回付ルート設定画面６２１は、通常の回付ルートを設定するための画面である。この回付ルート設定画面６２１においては、回付区分、必須・任意指定、部署、役職、従業員名称等を設定するための入力欄が含まれる。

回付区分欄では、「連絡」「承認（１）」〜「承認（ｎ）」、「配布」を設定する。
必須・任意指定欄では、回付先の作業について必須又は任意を指定する。
部署、役職、従業員名称の各欄では、回付先の部署、回付先のユーザの役職、回付先のユーザを特定するための情報を設定する。

代理承認設定画面６２２は、通常の回付ルートの承認者に対して、代理承認を行なう承認者を設定するための画面である。
メンテナンス画面６２３は、管理者がユーザのログイン状況を確認する場合に使用する。また、システムメンテナンスを行なう場合に、システムメンテナンスモードを設定することで一般ユーザによるログインを抑制する。

画面記憶部２６に記録された画面データ２６０は、図７に示すように、表示画面とスタイルシートとから構成されている。この表示画面とスタイルシートとは、後述するように、複数のフィールドからマトリックス状に配置されて構成されている。

スタイルシートにおいては、フィールド位置に対して、属種及びプロパティが記録されている。
フィールド位置は、画面においてフィールドが配置されている場所を特定するための情報である。
属種は、表示画面に入力された値の項目を特定するための情報である。

プロパティは、このフィールドに入力する値の条件に関する情報である。
表示画面においては、フィールド位置に対して、入力される属性（値）の入力欄が設けられている。
このように、画面データを介して、予め設定された属種と、画面において入力された属性（値）とが関連付けられる。

個別情報記憶部２７には、図７に示すように、申請されたジョブ（申請情報）を管理するための個別管理データ２７０が記録される。この個別管理データ２７０は、申請が登録された場合に記録される。個別管理データ２７０には、管理ＩＤ、属種、属性に関するデータを含んで構成される。

管理ＩＤデータ領域には、このジョブを特定するための識別子に関するデータが記録される。ここでは、管理ＩＤとして「ジョブＩＤ」又は「ジョブＩＤ及びドキュメントＩＤ」の組み合わせから構成される。ジョブの業務プロセス全体に共通な内容については、ジョブＩＤが設定される。一方、このジョブの業務プロセスを構成する一部の業務ステップの内容については、「ジョブＩＤ及びドキュメントＩＤ」が設定される。

属種データ領域には、登録された属性（値）の項目を特定するための識別子が記録される。例えば、ジョブＩＤに対する属種として、業務ＩＤ、件名、登録者、登録部署、登録日、ドキュメントＩＤ等に関するデータが記録される。また、任意の属種として、申請について最終承認希望日を設定することも可能である。更に、進捗状況として、現在の業務ステップのステップＩＤ、現在の業務ステップの登録者、回付先（承認者を含む）、各回付状態（未了、作業待ち、承認済、連絡済、配付済等）や、各承認者の承認期限等が含まれる。例えば、不適合に対応する業務プロセスにおいては、属種として、障害ランク、システム名、影響度、障害内容、作業状況等を含める。
属性（値）データ領域には、属種に対して入力された情報が記録される。このデータ領域には、数値やテキスト等が記録される。

なお、個別情報記憶部２７に記録する個別管理データ２７０は、表計算ファイルを用いて登録することも可能である。この場合には、図７に示すように、表計算ファイルのテンプレートファイル２６５を準備する。このテンプレートファイル２６５は、メインワークシートとフォーマットワークシートとから構成する。フォーマットワークシートにおいては、上述したスタイルシートと同様に、フィールド位置に対して属種やプロパティを設定しておく。そして、メインワークシートにおいて、フォーマットワークシートの同じフィールド位置に、属性（値）を設定できるようにしておく。このようなテンプレートファイル２６５に対して、属性（値）を設定した表計算ファイルを承認管理サーバ２０にインポートする。この場合、承認管理サーバ２０の制御部２１は、フォーマットワークシートに設定された属種に対して、メインワークシートに設定された属性（値）を記録した個別管理データ２７０を生成し、個別情報記憶部２７に登録する。

また、個別情報記憶部２７に記録されている個別管理データ２７０は、表計算ファイルに出力することも可能である。この場合にも、図７に示すテンプレートファイル２６５を用いる。フォーマットワークシートにおいては、フィールド位置に対して属種やプロパティを設定しておく。そして、メインワークシートにおいては、帳票のフレームを設けておくとともに、フォーマットワークシートの同じフィールド位置に、属性（値）を設定できるようにしておく。そして、ジョブＩＤ，ドキュメントＩＤを特定して、個別情報記憶部２７に登録されている個別管理データ２７０を抽出し、このテンプレートファイル２６５に対して、承認管理サーバ２０から、属性（値）を設定した表計算ファイルにエクスポートする。

（全体の概要）
次に、図８を用いて、全体の概要を説明する。
まず、承認管理サーバ２０の制御部２１は、システム設定処理を実行する（ステップＳ１−１）。具体的には、管理者は、クライアント端末１０を用いて、承認管理サーバ２０に格納された承認管理プログラムを起動する。この場合、承認管理サーバ２０の制御部２１の設定管理手段２１１は、クライアント端末１０のディスプレイに、図９（ａ）に示す初期設定画面５００を表示する。この初期設定画面５００においては、業務プロセス、台帳、メニュー、システム定義、画面定義、ラベル、メッセージ、メールについての初期設定を行なうことができる。この初期設定画面５００には、業務プロセス〜メールを選択するためのメニューボタンが含まれる。そして、特定のメニューボタンが選択された場合、選択されたメニューについての初期設定を行なうための作業画面が表示される。

業務プロセスの作業画面では、業務プロセスの名称、業務プロセスの説明、自動採番方式、業務プロセスに含まれる業務ステップを設定することができる。更に、設定された業務ステップに対して、図１０において後述する詳細作業画面５１０が表示される。この詳細作業画面５１０を用いることにより、申請時や承認時において用いる画面を生成することができる。

台帳の作業画面では、ジョブ台帳やドキュメント台帳についての台帳設定情報を入力することができる。
メニューの作業画面では、ユーザがアクセスした時のメニュー画面についてのメニュー設定情報を入力することができる。

システム定義の作業画面では、承認管理サーバ２０の動作環境についてのシステム定義設定情報を入力することができる。
画面定義の作業画面では、各実行画面を制御するための画面定義設定情報を入力することができる。

ラベルの作業画面では、各画面において配置されるアイコンのラベルについてのラベル設定情報を入力することができる。
メッセージの作業画面では、処理実行時のメッセージを入力することができる。
メールの作業画面では、メールの送信内容に関するメール設定情報を入力することができることができる。

そして、各作業画面においての初期設定の完了入力が行なわれた場合には、制御部２１の設定管理手段２１１は、各設定情報を設定情報記憶部２２に記録する。
ここで、業務プロセスの設定において使用する詳細作業画面５１０を、図１０を用いて説明する。この詳細作業画面５１０においては、申請や承認において用いる画面（例えば、ドキュメント登録画面６１１）を生成する。詳細作業画面５１０には、画面構成エリア５１１、フィールド属性設定エリア５１２、ステップ共通設定エリア５１３から構成される。

画面構成エリア５１１においては、申請や承認において表示される画面のレイアウトを設定する。このレイアウトは、マトリックス状に配置された複数のフィールドにより構成される。そして、各フィールドを特定して、フィールド属性設定エリア５１２において、フィールドの内容を特定する。

このフィールド属性設定エリア５１２においては、以下の設定を行なう。
「行」欄、「列」欄においては、属性を設定するフィールドを特定する。
「タイプ」欄においては、このフィールドにおいて設定される表示形式を指定する。例えば、「テキスト」や「テキスト（スクロール）」、「ダイアログ」、「ドロップダウン」等を指定することができる。

「ラベル」欄においては、このフィールドに貼り付けるラベルを設定する。
「属性」欄においては、このフィールドに表示又は入力する属性（値）の属種を設定する。

「属性詳細」欄においては、上記属性がパラメータ名を必要とする場合、そのパラメータ名を選択または設定する。
「入力制限」欄においては、このフィールドの入力条件を設定する。ここでは、「必須」、「任意」、「表示のみ」、「必須（手入力不可）」、「任意（手入力不可）」等から選択する。

「ドロップダウン」欄においては、「タイプ」欄において「ドロップダウン」を選択されている場合に、任意のドロップダウン名を指定する。
「ダイアログ」欄においては、「タイプ」欄において「ダイアログ」を選択されている場合に、任意のダイアログ名を設定する。

「初期値」欄においては、このフィールドにおけるデフォルト値を設定する。
「高さ」欄においては、タイプに「テキスト（スクロール）」を指定されている場合にフィールドの高さをピクセルで設定する。

「最小値」欄、「最大値」欄においては、このフィールドにおいて許可される最小値や最大値を設定する。この範囲を逸脱する値を入力して登録または回付開始を行なうことができなくなる。

「過去未来」欄においては、入力した日付が現在を基点にどれくらい超過していたらエラーとするかを設定する。この場合、過去のｎ日超過した日付を入力したらエラーとしたい場合は「−ｎ」と設定し、将来ｎ日を超過した日付を入力したらエラーとしたい場合は「ｎ」を設定する。
「ヘルプ」欄においては、フィールドに入力する値の説明をマウスオーバーによって表示する説明を設定する。なお、図１０のフィールド属性設定エリア５１２に表示されていない項目は、スクロールにより表示させることができる。

ステップ共通設定エリア５１３においては、以下の設定を行なう。
「ステップＩＤ」欄においては、業務プロセスを構成する業務ステップを特定するための識別子を設定する。

「ステップ名称」欄においては、業務ステップの名称を設定する。
「ステップ繰り返し」欄においては、この業務ステップでドキュメント登録を繰り返す場合には「繰り返しあり」を選択する。

「前ファイルコピー」欄においては、ファイルのコピー元のステップＩＤを設定する。
「ファイル名」欄においては、ドキュメント作成のテンプレートファイル名を設定する。

「メインシート」欄においては、ドキュメントに値を転記または取得するテンプレートファイル内のワークシート名を設定する。
「フォーマット」欄においては、ドキュメントに値を転記または取得するためのフォーマットを定義したテンプレートファイル内のワークシート名を設定する。

「前のステップ」欄においては、前のステップの状態によって、この業務ステップのドキュメント登録を制限する場合には、利用条件となる前の業務ステップのステップＩＤを設定する。

「前のステップの状態」欄には、利用条件として、前の業務ステップにおける状態を設定する。
「ドキュメントＩＤ自動採番」欄においては、ドキュメント作成時に、ドキュメントＩＤを自動採番する場合は、そのドキュメントＩＤ自動採番ルールを設定する。

「ドキュメント件名自動生成」欄においては、ドキュメント生成時にドキュメント件名を自動生成する場合の生成ルールを設定する。
「自動採番」欄においては、作成されるドキュメントのファイル名を自動採番する場合は、その採番ルールを設定する。

「アップロード」欄においては、ドキュメントをアップロードするときに、ユーザがファイル名の変更を許可するかどうかを指定する。
「スタイル」欄においては、画面のスタイル名を定義する。
「第３ボタンの機能」においては、このステップで作成したドキュメントについて回付が必要な場合は「回付依頼」を選択する。回付が不要な場合は「登録」を選択する。

「参照モード」欄においては、承認画面や台帳から登録したドキュメントを参照する場合に、ドキュメント登録画面６１１を参照モードで表示するか、ドキュメントを表示するかを選択する。

「回付ルートＩＤ」欄においては、この業務ステップで作成したドキュメントの回付ルートを特定するための識別子（回付ルートＩＤ）を設定する。
「回付ルートＩＤ（所属１）」欄においては、所属１単位に回付ルートを事前決定する場合に設定する。

「電子印フォーマット」欄においては、電子印機能を使用する場合、電子印フォーマットを設定する。
「配布時ドキュメント作成」欄においては、ドキュメントを自動作成するステップＩＤを設定する。

「承認期限」欄においては、ステップ別承認期限を設定する。
「次承認期限（ステップ）」欄、「次承認期限（日数）」欄においては、ステップ別に催促機能を設定する。
「同一所属制御」欄においては、ジョブの作成者とドキュメントの作成者との所属を制御することができる。

この詳細作業画面５１０により、図１０に示すドキュメント登録画面６１１が生成され、画面記憶部２６に登録される。ドキュメント登録画面６１１は、図７で説明したように、スタイルシートから構成されており、フィールド位置に対して、詳細作業画面５１０において設定された属種やプロパティが記録される。そして、ドキュメント登録画面６１１において入力された値（属性）は属種と関連付けられて、個別情報記憶部２７に登録される。

次に、図８に示すように、承認管理サーバ２０の制御部２１は、ユーザ登録処理を実行する（ステップＳ１−２）。具体的には、管理者は、クライアント端末１０を用いて、ユーザ登録を指示する。この場合、制御部２１の設定管理手段２１１は、図９（ｂ）に示すユーザ登録画面５０１をクライアント端末１０のディスプレイに出力する。このユーザ登録画面５０１においては、ユーザ情報（申請者、承認者、管理者）の登録、修正、削除を行なうことができる。ユーザ登録においては、上述のように従業員ＩＤ〜権限グループに関するデータを登録する。この場合、承認管理サーバ２０の制御部２１は、登録されたユーザ情報をユーザ記憶部２３に記録する。修正、削除においては、既に登録されているユーザを指定して、登録内容の修正や、ユーザ登録の削除を行なうことができる。

次に、承認管理サーバ２０の制御部２１は、回付ルート登録処理を実行する（ステップＳ１−３）。具体的には、管理者は、クライアント端末１０を用いて、回付ルート登録を指示する。この場合、制御部２１の設定管理手段２１１は、図９（ｃ）に示す回付ルート登録画面５０２をクライアント端末１０のディスプレイに出力する。この回付ルート登録画面５０２においては、申請についての回付ルートの新規登録、修正、複製、削除を行なうことができる。新規登録の場合には、回付区分、必須・任意指定、従業員名（ユーザ）を設定する。この場合、承認管理サーバ２０の制御部２１は、設定された回付ルート情報を回付ルート記憶部２５に記録する。

以上により、承認管理サーバ２０を使用するための事前登録を終了する。
そして、申請のためのジョブやドキュメントを登録する場合には、申請者は、クライアント端末１０を用いて、承認管理サーバ２０にアクセスする。そして、ユーザ認証を行なった後で、トップ画面６１０の作業選択において新規登録を指示する。

この場合、承認管理サーバ２０の制御部２１は、ジョブ登録処理を実行する（ステップＳ１−４）。具体的には、制御部２１の申請管理手段２１４は、ドキュメント登録画面６１１において設定された各属種、属性の組み合わせに対して、ジョブＩＤ、ドキュメントＩＤを付与した個別管理データ２７０を生成し、個別情報記憶部２７に登録する。この処理については、図１２を用いて後述する。そして、クライアント端末１０において、回付開始画面６１２を用いて、回付開始入力を行なう。なお、ここで、承認者を変更することも可能である。この処理については、図１３を用いて後述する。

回付開始情報を取得した承認管理サーバ２０の制御部２１は、進捗の更新処理を実行する（ステップＳ１−５）。具体的には、制御部２１の申請管理手段２１４は、個別情報記憶部２７において、回付開始が入力されたジョブＩＤ、ドキュメントＩＤが記録された個別管理データ２７０の進捗状況として「回付中」を登録する。

また、申請についての承認を行なう場合、承認者はクライアント端末１０を用いて、承認管理サーバ２０にアクセスして、ユーザ認証を行なう。
この場合、承認管理サーバ２０の制御部２１は、承認処理を実行する（ステップＳ１−６）。具体的には、制御部２１の画面制御手段２１３は、トップ画面６１０に、個別情報記憶部２７に記録されたジョブの進捗管理一覧を表示する。この処理については、図１４を用いて後述する。そして、承認者は、クライアント端末１０において、進捗管理一覧の中で、承認対象を選択する。更に、承認画面６１４を用いて、申請内容を確認して、承認入力を行なう。この処理については、図１５を用いて後述する。

次に、承認管理サーバ２０の制御部２１は、進捗の更新処理を実行する（ステップＳ１−７）。具体的には、制御部２１の承認管理手段２１５は、個別情報記憶部２７において、承認入力されたジョブＩＤ、ドキュメントＩＤが記録された個別管理データ２７０の進捗状況として「承認済」を登録する。

（画面制御処理）
次に、図１１を用いて、画面制御処理を説明する。この画面制御処理は、申請者がドキュメント登録を行なう場合や、承認者が承認処理を行なう場合に実行される。いずれの場合にも、クライアント端末１０を用いて承認管理サーバ２０にアクセスする。

この場合、承認管理サーバ２０の制御部２１は、ユーザ認証処理を実行する（ステップＳ２−１）。具体的には、制御部２１のユーザ認証手段２１２は、クライアント端末１０のディスプレイにユーザ認証画面を出力し、クライアント端末１０から従業員コード及び認証コードを取得する。そして、ユーザ認証手段２１２は、ディレクトリ管理サーバ４０を用いて、取得した従業員コード及び認証コードを照合する。照合できなかった場合には、ログインを拒絶する。

ユーザ認証を完了した場合、承認管理サーバ２０の制御部２１は、進捗一覧表示処理を実行する（ステップＳ２−２）。具体的には、制御部２１の画面制御手段２１３は、トップ画面において、このユーザの作業待ちジョブの一覧リストを表示する。この処理については、図１４を用いて後述する。

次に、承認管理サーバ２０の制御部２１は、進捗一覧から処理対象の選択処理を実行する（ステップＳ２−３）。具体的には、制御部２１の画面制御手段２１３は、進捗状況一覧に表示されたジョブが選択された場合には、選択された申請のジョブＩＤ及びドキュメントＩＤをクライアント端末１０から取得する。なお、新たな申請についてジョブ登録を行なう場合には、トップ画面において、新規登録対象の業務プロセスを選択する。この場合、画面制御手段２１３は、クライアント端末１０において選択された業務プロセスの業務ＩＤを取得する。

次に、承認管理サーバ２０の制御部２１は、表示画面の利用制御処理を実行する（ステップＳ２−４）。具体的には、制御部２１の画面制御手段２１３は、クライアント端末１０から、ジョブＩＤ及びドキュメントＩＤを取得した場合には、個別情報記憶部２７から、ジョブＩＤ及びドキュメントＩＤが記録された個別管理データ２７０を抽出し、個別管理データ２７０を用いて、現在の業務ステップについての業務ＩＤ、ステップＩＤを特定する。次に、画面制御手段２１３は、この業務ＩＤ、ステップＩＤに関連付けられた画面データを画面記憶部２６から取得する。そして、この画面データのプロパティにおいて、利用条件（「前のステップ」、「前のステップの状態」）を取得する。

ここで、利用条件が設定されている場合、画面制御手段２１３は、このジョブＩＤにおいて、前のステップＩＤの業務ステップの状態を個別情報記憶部２７において特定する。そして、画面制御手段２１３は、特定した前の業務ステップの状態が利用条件に一致する場合には、選択された業務ステップの画面を利用可能とする。なお、利用条件に一致しない場合には、画面制御手段２１３は、この業務ステップの処理を拒否する。

なお、クライアント端末１０から、新たな申請についての業務ＩＤを取得した場合、画面制御手段２１３は、選択された業務ＩＤが記録された業務プロセス管理レコード２４０を、業務プロセス記憶部２４を用いて特定する。次に、画面制御手段２１３は、業務プロセス管理レコード２４０において、最初のステップＩＤに関連付けられた画面データを画面記憶部２６から取得する。

次に、承認管理サーバ２０の制御部２１は、画面に設定された属種に対する属性の取得処理を実行する（ステップＳ２−５）。具体的には、制御部２１の画面制御手段２１３は、この業務ステップにおいて利用可能な画面のスタイルシートに設定されている属種を特定する。更に、画面制御手段２１３は、特定した属種について、選択された申請のジョブＩＤが管理ＩＤとして関連付けられた属性（値）を個別情報記憶部２７から取得する。更に、画面制御手段２１３は、特定した属種について、指定された申請のジョブＩＤ及びドキュメントＩＤが管理ＩＤとして関連付けられた属性（値）を個別情報記憶部２７から取得する。

次に、承認管理サーバ２０の制御部２１は、画面表示処理を実行する（ステップＳ２−６）。具体的には、制御部２１の画面制御手段２１３は、取得した属性（値）を、スタイルシートにおいて属種が設定されたフィールドに張り付けた表示画面を生成する。そして、画面制御手段２１３は、クライアント端末１０のディスプレイに、生成した表示画面を出力する。

次に、クライアント端末１０は、入力処理を実行する（ステップＳ２−７）。具体的には、クライアント端末１０において、ディスプレイに出力された表示画面の特定のフィールドに、所望の属性（値）を入力する。クライアント端末１０は入力された属性（値）を仮記憶する。

この場合、クライアント端末１０は、プロパティチェック処理を実行する（ステップＳ２−８）。具体的には、クライアント端末１０は、スタイルシートにおいて、このフィールドに設定されているプロパティを用いて、入力情報の適正性を確認する。プロパティに設定された条件を満たしている場合にはプロパティチェックのサクセスメッセージを出力する。一方、プロパティに設定された条件に合わない場合には、エラーメッセージを出力する。

そして、入力を終了した場合、表示画面において完了入力を行なう。
この場合、クライアント端末１０は、必須項目の記入漏れチェック処理を実行する（ステップＳ２−９）。具体的には、クライアント端末１０は、スタイルシートの各フィールドに設定されているプロパティを用いて、必須となっている属種についての属性入力の抜けを確認する。プロパティに設定された条件を満たしている場合には記入漏れチェックのサクセスメッセージを出力する。一方、プロパティに設定された条件に合わない場合には、エラーメッセージを出力する。なお、本実施形態では、クライアント端末１０においてプロパティチェック及び記入漏れチェックを行なったが、承認管理サーバ２０の制御部２１において実行するようにしてもよい。この場合には、制御部２１の画面制御手段２１３が、クライアント端末１０から入力された情報を取得し、各フィールドのプロパティと照合して、プロパティチェックや記入漏れチェックを行なう。

次に、承認管理サーバ２０の制御部２１は、データ登録処理を実行する（ステップＳ２−１０）。具体的には、制御部２１の画面制御手段２１３は、クライアント端末１０において入力されたデータを取得する。ここでは、属種に関連付けて属性（値）を取得する。そして、画面制御手段２１３は、ジョブＩＤ及びドキュメントＩＤに関連づけて、属種に対応させて属性（値）を記録した個別管理データ２７０を生成し、個別情報記憶部２７に登録する。

次に、承認管理サーバ２０の制御部２１は、進捗の更新処理を実行する（ステップＳ２−１１）。具体的には、制御部２１の画面制御手段２１３は、個別情報記憶部２７に記憶された、このジョブについての個別管理データ２７０の進捗状況として「作成中」を更新する。

（申請登録処理）
次に、図１２を用いて、申請登録処理を説明する。ここでは、クライアント端末１０のディスプレイに表示されたトップ画面において、新規登録が選択された場合に実行される。この場合、制御部２１の画面制御手段２１３は、ドキュメント登録画面６１１を、クライアント端末１０のディスプレイに出力する。

まず、承認管理サーバ２０の制御部２１は、申請の受付処理を実行する（ステップＳ３−１）。具体的には、制御部２１の画面制御手段２１３は、ドキュメント登録画面６１１において設定された申請内容を取得する。この場合、画面制御手段２１３は、申請管理手段２１４に処理を引き継ぐ。

次に、承認管理サーバ２０の制御部２１は、申請に基づいて業務プロセスの特定処理を実行する（ステップＳ３−２）。具体的には、制御部２１の申請管理手段２１４は、ドキュメント登録画面６１１の業務ＩＤに基づいて、業務プロセスを特定する。

次に、承認管理サーバ２０の制御部２１は、承認者毎に通常の猶予期間の設定処理を実行する（ステップＳ３−３）。具体的には、制御部２１の申請管理手段２１４は、特定した業務プロセスにおける回付ルートを回付ルート記憶部２５から取得する。次に、申請管理手段２１４は、回付ルートに含まれる各承認者の役職を特定する。そして、申請管理手段２１４は、特定した各役職に関連付けられた猶予期間を猶予期間テーブルから取得する。

次に、承認管理サーバ２０の制御部２１は、最終承認予定日の算出処理を実行する（ステップＳ３−４）。具体的には、制御部２１の申請管理手段２１４は、システムタイマから現在日付を取得し、この現在日付に対して、回付ルートに含まれる各承認者に対して、順次、猶予期間を加算した承認期限を算出する。そして、申請管理手段２１４は、最終承認者の承認期限を最終承認予定日として算出する。

次に、承認管理サーバ２０の制御部２１は、最終承認予定日の出力処理を実行する（ステップＳ３−５）。具体的には、制御部２１の申請管理手段２１４は、クライアント端末１０のディスプレイに確認画面を出力する。この確認画面には、算出した最終承認予定日とともに、最終承認予定日について調整が必要かどうかを選択するためのアイコンが含まれる。更に、個別情報記憶部２７に記録された個別管理データ２７０に申請の最終承認希望日が登録されている場合には、申請管理手段２１４は、最終承認希望日と最終承認予定日とを比較する。そして、最終承認予定日が最終承認希望日よりも遅い場合には、注意を喚起するためのメッセージを確認画面に含める。

次に、承認管理サーバ２０の制御部２１は、期限調整が必要かどうかについての判定処理を実行する（ステップＳ３−６）。具体的には、制御部２１の申請管理手段２１４は、確認画面において選択されたアイコンに基づいて、調整要否を判定する。

「調整不要」のアイコンが選択され、期限調整は必要でないと判定した場合（ステップＳ３−６において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、各承認期限の登録処理を実行する（ステップＳ３−７）。具体的には、制御部２１の申請管理手段２１４は、回付ルートに含まれる各承認者に対して算出した承認期限を、個別情報記憶部２７において、各承認者の従業員コードに関連づけて登録する。具体的には、属性として、業務ステップ毎に、承認者の従業員ＩＤ、業務ステップ別の承認期限を記録した個別管理データ２７０を、それぞれ生成し、個別情報記憶部２７に記録する。

一方、「調整必要」のアイコンが選択され、期限調整が必要と判定した場合（ステップＳ３−６において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、調整画面の出力処理を実行する（ステップＳ３−８）。具体的には、制御部２１の申請管理手段２１４は、クライアント端末１０のディスプレイに、期限調整画面を出力する。この期限調整画面には、承認者毎に算出した承認期限を含める。そして、この承認期限を、クライアント端末１０において修正可能にしておく。申請者は、クライアント端末１０のディスプレイに出力された調整画面において、最終承認予定日を考慮して、各承認者の承認期限を調整する。

次に、承認管理サーバ２０の制御部２１は、調整された各承認期限の登録処理を実行する（ステップＳ３−９）。具体的には、制御部２１の申請管理手段２１４は、クライアント端末１０から、期限調整画面において設定された承認期限を取得する。そして、申請管理手段２１４は、調整された承認期限を、各承認者の従業員コードに関連付けて個別情報記憶部２７に記録する。ここでも、属性として、業務ステップ毎に、承認者の従業員ＩＤ、業務ステップ別の承認期限を記録した個別管理データ２７０を、それぞれ生成し、個別情報記憶部２７に記録する。

（承認者変更処理）
次に、図１３を用いて、承認者変更処理を説明する。ここでは、通常の回付ルートにおいて設定された承認者を他の承認者に変更する場合を想定する。

まず、承認管理サーバ２０の制御部２１は、承認者の変更入力処理を実行する（ステップＳ４−１）。具体的には、クライアント端末１０のディスプレイに表示された回付進捗詳細画面６１６において、変更対象の申請を特定する。そして、クライアント端末１０を用いて、承認者の変更アイコンを選択する。この場合、制御部２１の画面制御手段２１３は、クライアント端末１０のディスプレイに承認者変更画面６１７を出力する。そして、ユーザは、承認者変更画面６１７において、新たな承認者を指定する。

次に、承認管理サーバ２０の制御部２１は、所属が同一部署かどうかについての判定処理を実行する（ステップＳ４−２）。具体的には、制御部２１の申請管理手段２１４は、ユーザ記憶部２３から、新たに登録された承認者のユーザ管理レコード２３０と、元の承認者のユーザ管理レコード２３０とを取得する。そして、申請管理手段２１４は、取得したユーザ管理レコード２３０を用いて、新たに登録された承認者の所属部署と元の承認者の所属部署とを比較する。

新たに登録された承認者の所属部署と、変更前の承認者の所属部署とが同一でないと判定した場合（ステップＳ４−２において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、確認通知処理を実行する（ステップＳ４−３）。具体的には、制御部２１の申請管理手段２１４は、変更前の承認者のメールアドレスをユーザ管理レコード２３０から取得する。そして、申請管理手段２１４は、このメールアドレスに対して、変更入力が行なわれたことを通知するための電子メールを送信する。この電子メールを確認した元の承認者は変更可否を判定する。そして、問題がない場合には、変更許可連絡を承認管理サーバ２０に返信する。変更前の承認者のクライアント端末１０から変更許可連絡を受けた場合には、承認管理サーバ２０の制御部２１は、ステップＳ４−６以降の処理を実行する。

一方、新たに登録された承認者の所属部署と、変更前の承認者の所属部署とが同一と判定した場合（ステップＳ４−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、権限レベルが同等以上かどうかについての判定処理を実行する（ステップＳ４−４）。具体的には、制御部２１の申請管理手段２１４は、取得したユーザ管理レコード２３０を用いて、新たに登録された承認者の役職と、変更前の承認者の役職とを比較する。

新たに登録された承認者の役職が、変更前の承認者の役職より低く、権限レベルが低いと判定した場合（ステップＳ４−４において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、変更拒絶処理を実行する（ステップＳ４−５）。具体的には、制御部２１の申請管理手段２１４は、クライアント端末１０に対して、承認者を変更できないことを示すメッセージを出力する。

一方、新たに登録された承認者の役職が、変更前の承認者の役職以上であり、権限レベルが同等以上と判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、変更登録処理を実行する（ステップＳ４−６）。具体的には、制御部２１の申請管理手段２１４は、個別情報記憶部２７において、ジョブＩＤが記録された個別管理データ２７０において、指定された変更前の承認者の従業員コードを、新たに指定された承認者の従業員コードに変更する。

次に、承認管理サーバ２０の制御部２１は、承認者毎に通常の猶予期間の設定処理を実行する（ステップＳ４−７）。具体的には、制御部２１の申請管理手段２１４は、必須の承認者であって、承認が終わっていない承認者を特定する。そして、申請管理手段２１４は、猶予期間テーブルから、各承認者の役職に対応する猶予期間を取得する。

次に、承認管理サーバ２０の制御部２１は、最終承認予定日の算出処理を実行する（ステップＳ４−８）。具体的には、制御部２１の申請管理手段２１４は、システムタイマから現在日時を取得し、未承認の承認者の猶予期間を加算することにより、最終承認予定日を算出する。

次に、承認管理サーバ２０の制御部２１は、ステップＳ３−６〜Ｓ３−９と同様に、期限調整が必要かどうかについての判定処理（ステップＳ４−９）、各承認期限の登録処理（ステップＳ４−１０）、調整画面の出力処理（ステップＳ４−１１）、調整された各承認期限の登録処理（ステップＳ４−１２）を実行する。

（進捗一覧管理処理）
次に、図１４を用いて進捗一覧管理処理を説明する。
まず、承認管理サーバ２０の制御部２１は、ユーザの特定処理を実行する（ステップＳ５−１）。具体的には、制御部２１のユーザ認証手段２１２は、クライアント端末１０から取得した従業員コード及び認証コードに基づいて、ユーザ認証を行なうことにより、ユーザを特定する。

次に、承認管理サーバ２０の制御部２１は、ユーザが承認者となっている申請の抽出処理を実行する（ステップＳ５−２）。具体的には、制御部２１の画面制御手段２１３は、個別情報記憶部２７において、認証されたユーザの従業員コードが承認者として登録されているジョブの個別管理データ２７０を抽出する。そして、画面制御手段２１３は、抽出した個別管理データ２７０に記録されている管理ＩＤにより、ジョブＩＤを特定する。

次に、承認管理サーバ２０の制御部２１は、承認予定リストの作成処理を実行する（ステップＳ５−３）。具体的には、制御部２１の画面制御手段２１３は、抽出したジョブを一覧表示させた承認予定リストを作成する。ここでは、画面制御手段２１３は、ジョブＩＤが記録された個別管理データ２７０を個別情報記憶部２７から抽出する。そして、画面制御手段２１３は、この承認予定リストにおいて、個別管理データ２７０を用いて各ジョブの進捗状況を表示させる。

次に、承認管理サーバ２０の制御部２１は、承認期限が近い順番での並び替え処理を実行する（ステップＳ５−４）。具体的には、制御部２１の画面制御手段２１３は、抽出した個別管理データ２７０を用いて、このユーザにおける作業待ちとなっている各ジョブの承認期限を特定する。そして、画面制御手段２１３は、承認予定リストにおいて、承認期限が近いものから、ジョブを順番に並び替える。

次に、承認管理サーバ２０の制御部２１は、承認予定リストの表示処理を実行する（ステップＳ５−５）。具体的には、制御部２１の画面制御手段２１３は、トップ画面６１０において、作成した承認予定リストを「作業待ち」として出力する。

（承認時処理）
次に、図１５を用いて、承認時処理を説明する。ここでは、承認者が承認入力を行なった場合に実行される。

まず、承認管理サーバ２０の制御部２１は、承認情報の取得処理を実行する（ステップＳ６−１）。具体的には、制御部２１の画面制御手段２１３は、承認者のクライアント端末１０から、承認画面において入力された承認情報を取得する。この場合、画面制御手段２１３は、承認管理手段２１５に処理を引き継ぐ。

次に、承認管理サーバ２０の制御部２１は、全業務ステップを終了したかどうかについての判定処理を実行する（ステップＳ６−２）。具体的には、制御部２１の承認管理手段２１５は、個別情報記憶部２７に記録された個別管理データ２７０の進捗状況に基づいて判定する。ここで、業務プロセス記憶部２４に記録された業務ステップにおいて、すべての回付先の承認が完了している場合には、全業務ステップを終了したと判定する。

全業務ステップを終了と判定した場合（ステップＳ６−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、完了通知処理を実行する（ステップＳ６−３）。具体的には、制御部２１の承認管理手段２１５は、個別情報記憶部２７において、承認されたジョブＩＤに記録された個別管理データ２７０を用いて申請者の従業員コードを特定する。次に、承認管理手段２１５は、特定した従業員コードが記録されたユーザ管理レコード２３０をユーザ記憶部２３から抽出してメールアドレスを取得する。そして、承認管理手段２１５は、このメールアドレスに対して、最終承認を完了したことを通知するための電子メールを送信する。

一方、全業務ステップを終了していないと判定した場合（ステップＳ６−２において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、現在の業務ステップを終了したかどうかについての判定処理を実行する（ステップＳ６−４）。具体的には、制御部２１の承認管理手段２１５は、個別情報記憶部２７において、承認されたジョブＩＤが記録されている個別管理データ２７０を用いて特定した進捗状況に基づいて判定する。ここでは、現在の業務ステップにおいて、回付区分が必須の回付先の承認が完了している場合には、現在の業務ステップを終了したと判定する。

現在の業務ステップを終了したと判定した場合（ステップＳ６−４において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、次の業務ステップへの展開処理を実行する（ステップＳ６−５）。具体的には、制御部２１の承認管理手段２１５は、業務プロセス記憶部２４において、このジョブの次の業務ステップを特定する。一方、現在の業務ステップを終了していないと判定した場合（ステップＳ６−４において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、次の業務ステップへの展開処理（ステップＳ６−５）をスキップする。

次に、承認管理サーバ２０の制御部２１は、展開可能な回付先があるかどうかについての判定処理を実行する（ステップＳ６−６）。具体的には、制御部２１の承認管理手段２１５は、現在の業務ステップを終了していない場合には、承認されたジョブＩＤが記録されている個別管理データ２７０を用いて、現在の業務ステップにおいて次の回付先を検索する。また、次の業務ステップに展開した場合には、新たな業務ステップにおいて最初の回付先を検索する。

展開可能な回付先がないと判定した場合（ステップＳ６−６において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、承認時処理を終了する。
一方、展開可能な回付先があると判定した場合（ステップＳ６−６において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、回付先が承認者かどうかについての判定処理を実行する（ステップＳ６−７）。具体的には、制御部２１の承認管理手段２１５は、回付ルート記憶部２５において、次の回付先の回付区分を特定し、この回付区分により承認者かどうかを判定する。

ここで、回付先が承認者でないと判定した場合（ステップＳ６−７において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、回付登録処理を実行する（ステップＳ６−８）。具体的には、制御部２１の承認管理手段２１５は、個別情報記憶部２７において、ジョブＩＤ、ドキュメントＩＤが記録された個別管理データ２７０の新たな回付先に対して、進捗状況として回付状態（連絡済、配付済等）を登録する。

一方、回付先が承認者と判定した場合（ステップＳ６−７において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、承認期限の再調整処理を実行する（ステップＳ６−９）。具体的には、制御部２１の承認管理手段２１５は、システムタイマから現在日付を取得する。

次に、承認管理手段２１５は、猶予期間テーブルから、後続の承認者についての猶予期間を取得する。そして、承認管理手段２１５は、現在日付に対して、承認者毎に、順次、猶予期間を加算して、承認期限を再計算し、個別情報記憶部２７において、承認期限が記録されている個別管理データ２７０を更新する。

次に、承認管理サーバ２０の制御部２１は、次の承認者に展開登録処理を実行する（ステップＳ６−１０）。具体的には、制御部２１の承認管理手段２１５は、個別情報記憶部２７において、この承認者の進捗状況が記録されている個別管理データ２７０において作業待ちを登録する。

本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、業務プロセスにおいては、複数の業務ステップから構成される。各業務ステップにおいては、回付ルートにおいて定められた部署、役職、個人への回付（連絡や承認）が行なわれる。そして、承認時処理において、全業務ステップを終了していないと判定した場合（ステップＳ６−２において「ＮＯ」の場合）であって、現在の業務ステップを終了したと判定した場合（ステップＳ６−４において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、次の業務ステップへの展開処理を実行する（ステップＳ６−５）。これにより、一つの業務プロセスを複数の業務ステップから構成することにより、業務プロセスの構成の自由度を確保することができる。従って、新たな業務プロセスを、既存の業務ステップを組み合わせて、効率的に作成することができる。

（２）本実施形態では、ドキュメント登録画面６１１において入力された値（属性）は属種と関連付けられて、個別情報記憶部２７に登録される。個別情報記憶部２７には、承認について申請されたジョブを管理するための個別管理データ２７０が記録される。個別管理データ２７０には、管理ＩＤ、属種、属性に関するデータを含んで構成される。これにより、属種と属性（値）とを関連付けて記憶するので、属種を増やす等のデータ構成の変更等の自由度を高くすることができる。従って、データ構成の修正作業の負荷を軽減することができる。

（３）本実施形態では、承認管理サーバ２０の制御部２１は、表示画面の利用制御処理を実行する（ステップＳ２−４）。具体的には、制御部２１の画面制御手段２１３は、画面記憶部２６に記録された画面データのプロパティにおいて、利用条件（「前のステップ」、「前のステップの状態」）を取得する。そして、利用条件が設定されている場合、画面制御手段２１３は、このジョブＩＤにおいて、前のステップＩＤの業務ステップの状態を個別情報記憶部２７において特定する。そして、画面制御手段２１３は、特定した前の業務ステップの状態が利用条件に一致する場合には、選択された業務ステップの画面を利用可能とする。これにより、画面データに設定されているプロパティを用いて、業務ステップにおける情報入力や表示を制限することができる。

（４）本実施形態では、承認管理サーバ２０の制御部２１は、画面表示処理を実行する（ステップＳ２−６）。具体的には、制御部２１の画面制御手段２１３は、取得した属性（値）を、スタイルシートにおいて属種が設定されたフィールドに張り付けた表示画面を生成する。これにより、個別情報記憶部２７に記録された属性（値）を用いて、表示画面を出力することができる。

（５）本実施形態では、承認管理サーバ２０の制御部２１は、承認者毎に通常の猶予期間の設定処理を実行する（ステップＳ３−３）。これにより、承認者の属性に応じて、各承認者の承認期限を設定することができる。

（６）本実施形態では、承認管理サーバ２０の制御部２１は、最終承認予定日の出力処理を実行する（ステップＳ３−５）。「調整必要」のアイコンが選択され、期限調整が必要と判定した場合（ステップＳ３−６において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、調整画面の出力処理を実行する（ステップＳ３−８）。これにより、最終承認予定日を考慮して、各承認者の承認期限を調整することができる。

（７）本実施形態では、承認者変更処理において、新たに登録された承認者の所属部署と、変更前の承認者の所属部署とが同一でないと判定した場合（ステップＳ４−２において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、確認通知処理を実行する（ステップＳ４−３）。これにより、元の承認者の承諾の下に、申請を他の部署に展開することができる。

（８）本実施形態では、承認者変更処理において、新たに登録された承認者の役職が、変更前の承認者の役職以上であり、権限レベルが同等以上と判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、変更登録処理を実行する（ステップＳ４−６）。これにより、権限レベルに応じて、承認者を効率的に変更することができる。

（９）本実施形態では、承認者変更処理において、承認管理サーバ２０の制御部２１は、最終承認予定日の算出処理を実行する（ステップＳ４−８）。そして、承認管理サーバ２０の制御部２１は、期限調整が必要かどうかについての判定処理（ステップＳ４−９）、各承認期限の登録処理（ステップＳ４−１０）、調整画面の出力処理（ステップＳ４−１１）、調整された各承認期限の登録処理（ステップＳ４−１２）を実行する。これにより、承認者を変更した場合においても、最終承認予定日を考慮した承認期限の調整を行なうことができる。

（１０）本実施形態では、進捗一覧管理処理において、承認管理サーバ２０の制御部２１は、承認期限が近い順番での並び替え処理を実行する（ステップＳ５−４）。これにより、承認者は、承認期限を考慮して、承認作業を行なうことができる。

（１１）本実施形態では、承認時処理において、承認管理サーバ２０の制御部２１は、承認期限の再調整処理を実行する（ステップＳ６−９）。これにより、進捗状況に応じて、後続の回付先の承認期限を調整することができる。

なお、上記各実施形態は以下のように変更してもよい。
・ 上記実施形態では、進捗一覧管理処理において、承認期限が近い順番での並び替え処理を実行する（ステップＳ５−４）。これに加えて、承認者のスケジュールに応じて、承認者に対して注意喚起を行なうようにしてもよい。この場合には、ユーザ（従業員）のスケジュールを管理するスケジュール管理サーバを用いる。このスケジュール管理サーバにおいては、ユーザの従業員コードに関連付けて、休暇や出張の日程情報等、承認対応できないイベント期間を登録しておく。そして、図１６に示す進捗一覧管理処理を実行する。

ここでは、ステップＳ５−１〜Ｓ５−４と同様に、承認管理サーバ２０の制御部２１は、ユーザの特定処理（ステップＳ７−１）〜承認期限が近い順番での並び替え処理（ステップＳ７−４）を実行する。

次に、承認管理サーバ２０の制御部２１は、ユーザのスケジュールの取得処理を実行する（ステップＳ７−５）。具体的には、制御部２１の画面制御手段２１３は、現在日付から、最も遅い承認期限までの期間について、スケジュール管理サーバから、この承認者のスケジュール（イベント期間）を取得する。

次に、承認管理サーバ２０の制御部２１は、スケジュールと承認期限との照合処理を実行する（ステップＳ７−６）。具体的には、制御部２１の画面制御手段２１３は、個別情報記憶部２７において、各ジョブのジョブＩＤが記録された個別管理データ２７０を用いて、この承認者の直前の先行承認者の承認期限を取得する。次に、画面制御手段２１３は、先行承認者の承認期限から、この承認者の承認期限までの承認期間を算出する。そして、画面制御手段２１３は、算出した承認期間と、承認対応ができないイベントが登録されたイベント期間とを比較する。

次に、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ７−７）。具体的には、制御部２１の画面制御手段２１３は、承認期間がイベント期間で満たされている申請を特定する。そして、画面制御手段２１３は、特定した申請に対して、承認予定リストにおいて注意情報を付加する。

そして、承認管理サーバ２０の制御部２１は、ステップＳ５−５と同様に、承認予定リストの表示処理を実行する（ステップＳ７−８）。
これにより、承認者のスケジュールを考慮して、承認が困難な申請について注意喚起することができる。

なお、この注意喚起は、申請登録処理において行なうようにしてもよい。具体的には、申請について、各承認者の承認期限を算出した場合、制御部２１の申請管理手段２１４は、各承認者のスケジュールを取得する。次に、申請管理手段２１４は、各承認者の承認期間（先行承認者の承認期限から各承認者の承認期限までの期間）を算出する。次に、申請管理手段２１４は、スケジュール管理サーバから、各承認者のスケジュール（イベント期間）を取得する。そして、各承認者において承認対応ができないイベントが登録されたイベント期間と比較する。ここで、申請管理手段２１４は、承認期間がイベント期間で満たされている場合には、申請者に対して注意喚起を行なう。

また、この注意喚起を行なうタイミングは、進捗一覧管理処理に限定されるものではない。例えば、業務プロセスの途中で承認者が変更された場合や、承認者が承認を行なうことができないイベント期間が登録された場合に行なうようにしてもよい。具体的には、制御部２１の承認管理手段２１５が、承認者の変更や、各承認者のイベント登録を検出した場合、個別情報記憶部２７を用いて、この承認者が登録された個別管理データ２７０を検索する。そして、承認管理手段２１５は、抽出した個別管理データ２７０を用いて、この承認者の承認期間とイベント期間とを比較する。そして、承認管理手段２１５は、承認期間がイベント期間で満たされている場合には、申請者に対して注意喚起を行なう。

・ 上記実施形態では、猶予期間テーブルを用いて、各承認者の承認期限を算出する。この猶予期間テーブルにおいては、各承認者の役職に対応させて、現在日付から承認期限を算出するための猶予期間に関するデータが記録されている。ここで、承認者のスケジュールに応じて、猶予期間を変更するようにしてもよい。この場合には、スケジュール管理サーバから、各承認者について登録されたイベント情報を取得する。そして、各承認者において、すべての承認期間に対して、イベント期間が重複しないように、猶予期間を延長又は短縮する。これにより、承認者のスケジュールに応じた承認期限を設定することができる。

・ 上記実施形態では、進捗一覧管理処理において、承認管理サーバ２０の制御部２１は、承認予定リストの表示処理を実行する（ステップＳ５−５）。ここで、申請内容について、承認者に対して事前説明が行なわれている場合には、承認予定リストにおいて事前説明済みを表示させるようにしてもよい。この場合には、申請登録処理において、回付ルートに含まれる承認者を特定して、事前説明を行なった承認者について事前説明済み情報を入力する。この場合、個別情報記憶部２７において、ジョブＩＤ、承認者の従業員コードが記録された個別管理データ２７０に、事前説明済みフラグを記録する。そして、制御部２１の画面制御手段２１３は、この事前説明済みフラグが記録されている承認者の承認予定リストに、事前説明済み情報を出力する。これにより、承認者は、事前説明を考慮して効率的に承認を行なうことができる。

また、事前説明済みフラグが記録されている承認者については、承認期限を算出するための猶予期間を短縮するようにしてもよい。この場合には、猶予期間テーブルにおいて、事前説明済みの申請について、短縮された猶予期間を算出するための情報を登録しておく。そして、制御部２１の申請管理手段２１４は、ステップＳ４−７において、事前説明済みフラグが記録されている承認者については、短縮された猶予期間を算出する。これにより、事前説明を行なっている場合には、承認期限の前倒しにより迅速な回付を行なうことができる。

・ 上記実施形態では、進捗一覧管理処理において、承認期限が近い順番での並び替え処理を実行する（ステップＳ５−４）。これに加えて、人事異動を考慮して承認予定リストを作成するようにしてもよい。この場合には、ユーザ（従業員）の人事異動を管理する人事管理サーバを用いる。この人事管理サーバにおいては、ユーザの従業員コードに関連付けて、異動予定日、人事内容を登録しておく。そして、図１７に示す進捗一覧管理処理を実行する。

ここでは、ステップＳ５−１〜Ｓ５−４と同様に、承認管理サーバ２０の制御部２１は、ユーザの特定処理（ステップＳ８−１）〜承認期限が近い順番での並び替え処理（ステップＳ８−４）を実行する。

次に、承認管理サーバ２０の制御部２１は、人事異動情報の取得処理を実行する（ステップＳ８−５）。具体的には、制御部２１の画面制御手段２１３は、人事管理サーバにアクセスし、このユーザ（ここでは、承認者）の人事異動情報（異動予定日及び異動先）を取得する。

次に、承認管理サーバ２０の制御部２１は、異動予定があるかどうかについての判定処理を実行する（ステップＳ８−６）。具体的には、制御部２１の画面制御手段２１３は、人事管理サーバから取得した人事異動情報に基づいて、この承認者の人事異動の有無を判定する。

異動予定があると判定した場合（ステップＳ８−６において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、承認期限が異動予定日から所定日数内の申請の特定処理を実行する（ステップＳ８−７）。具体的には、制御部２１の画面制御手段２１３は、直前の先行承認者の承認期限から、この承認者の承認期限までの承認期間を算出する。そして、画面制御手段２１３は、人事異動情報に含まれる異動予定日と承認期間とを比較し、承認期間に異動予定日が含まれる申請を特定する。

次に、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ８−８）。具体的には、制御部２１の画面制御手段２１３は、特定した申請に対して、承認予定リストにおいて異動予定日が近いことを示す注意情報を付加する。

次に、承認管理サーバ２０の制御部２１は、承認期限が異動予定日から所定日数以上遅い申請の特定処理を実行する（ステップＳ８−９）。具体的には、制御部２１の画面制御手段２１３は、直前の先行承認者の承認期限（承認期間の初日）が異動予定日より遅い申請を特定する。

次に、承認管理サーバ２０の制御部２１は、承認予定リストから削除処理を実行する（ステップＳ８−１０）。具体的には、制御部２１の画面制御手段２１３は、特定した申請について、承認予定リストから削除する。

なお、異動予定がないと判定した場合（ステップＳ８−６において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、ステップＳ８−７〜Ｓ８−１０の処理をスキップする。また、人事異動予定があっても、同じ部署における昇格の場合には、ステップＳ８−７〜Ｓ８−１０の処理をスキップするようにしてもよい。

次に、承認管理サーバ２０の制御部２１は、ステップＳ５−５と同様に、承認予定リストの表示処理を実行する（ステップＳ８−１１）。
これにより、人事異動が近い場合には、承認者に対して注意喚起することにより、迅速な承認を促すことができる。また、承認時期に承認者が異動する可能性がある申請は、異動予定者に見せないようにすることができる。

なお、この注意喚起は、申請登録処理において行なうようにしてもよい。具体的には、申請について、各承認者の承認期限を算出した場合、画面制御手段２１３は、各承認者の異動情報を取得する。次に、画面制御手段２１３は、各承認者の承認期間（先行承認者の承認期限から各承認者の承認期限までの期間）を算出し、各承認者の異動情報に含まれる異動予定日と比較する。そして、画面制御手段２１３は、異動予定日から承認期限までが基準日数内の申請や、異動予定日が承認期間より遅い場合には、申請者に対して注意喚起を行なう。

・ 上記実施形態では、申請登録処理において、承認管理サーバ２０の制御部２１は、最終承認予定日の算出処理（ステップＳ３−４）、最終承認予定日の出力処理（ステップＳ３−５）を実行する。そして、クライアント端末１０における入力に基づいて、承認管理サーバ２０の制御部２１は、期限調整が必要かどうかについての判定処理を実行する（ステップＳ３−６）。ここで、承認管理サーバ２０が承認期限を調整するようにしてもよい。この場合には、個別情報記憶部２７に、申請時に、管理ＩＤ（ジョブＩＤ）、最終承認希望日を記録した個別管理データ２７０を登録しておく。更に、猶予期間テーブルに、猶予期間を短縮するための圧縮率を記録しておく。そして、図１８に示す申請登録処理を実行する。

ここでは、承認管理サーバ２０の制御部２１は、ステップＳ３−１〜Ｓ３−４と同様に、申請の受付処理（ステップＳ９−１）、申請に基づいて業務プロセスの特定処理（ステップＳ９−２）、承認者毎に通常の猶予期間を設定処理（ステップＳ９−３）、最終承認予定日の算出処理（ステップＳ９−４）を実行する。

次に、承認管理サーバ２０の制御部２１は、最終承認希望日までに間に合うかどうかについての判定処理を実行する（ステップＳ９−５）。具体的には、制御部２１の申請管理手段２１４は、個別情報記憶部２７を用いて、この申請についてのジョブＩＤが記録された個別管理データ２７０から最終承認希望日を取得し、算出した最終承認予定日と比較する。

最終承認予定日が最終承認希望日以前であり、最終承認希望日に間に合うと判定した場合（ステップＳ９−５において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、ステップＳ３−７と同様に、各承認期限の登録処理を実行する（ステップＳ９−６）。

一方、最終承認予定日が最終承認希望日より遅く、最終承認希望日に間に合わないと判定した場合（ステップＳ９−５において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、承認者毎に猶予期間の圧縮処理を実行する（ステップＳ９−７）。具体的には、制御部２１の申請管理手段２１４は、猶予期間テーブルに記録された猶予期間に対して、予め定められた圧縮率を乗算した修正猶予期間を算出する。

次に、承認管理サーバ２０の制御部２１は、最終承認予定日の再算出処理を実行する（ステップＳ９−８）。具体的には、制御部２１の申請管理手段２１４は、現在日付に対して、回付ルートに含まれる各承認者に対して、順次、修正猶予期間を加算した承認期限を算出する。そして、申請管理手段２１４は、再度、最終承認者の承認期限を最終承認予定日として算出する。

次に、承認管理サーバ２０の制御部２１は、ステップＳ９−５と同様に、最終承認希望日までに間に合うかどうかについての判定処理を実行する（ステップＳ９−９）。
最終承認予定日が最終承認希望日以前であり、最終承認希望日に間に合うと判定した場合（ステップＳ９−９において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、各承認期限の登録処理を実行する（ステップＳ９−６）。

一方、最終承認予定日が最終承認希望日より遅く、最終承認希望日に間に合わないと判定した場合（ステップＳ９−９において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、ステップＳ３−８、Ｓ３−９と同様に、調整画面の出力処理（ステップＳ９−１０）、調整された各承認期限の登録処理（ステップＳ９−１１）を実行する。
これにより、猶予期間を調整して、状況に応じて、最終承認希望日に間に合う承認期限を設定することができる。

また、業務プロセスの途中で、定期的に最終承認予定日の再計算を行なうようにしてもよい。そして、通常の猶予期間を適用して算出した最終承認予定日が最終承認希望日に間に合う場合には、通常の猶予期間を用いて、各承認者の承認期限を再設定する。これにより、承認が前倒しで行なわれている場合には、通常の猶予期間に戻すことができる。

・ 上記実施形態では、猶予期間テーブルを用いて、各承認者の承認期限を算出する。ここで、一つの業務プロセスにおいて、複数の業務ステップを並行して行なうことがある。この場合には、並行して行なわれる業務ステップを考慮して承認期限を算出するようにしてもよい。ここでは、最終承認までのクリティカルパスを特定し、クリティカルパスを構成する業務ステップの所要期間を用いて、各業務ステップの承認期限を設定する。この申請登録処理を、図１９を用いて説明する。

ここでは、承認管理サーバ２０の制御部２１は、ステップＳ３−１、ステップＳ３−２と同様に、申請の受付処理（ステップＳ１０−１）、申請に基づいて業務プロセスの特定処理（ステップＳ１０−２）を実行する。

次に、承認管理サーバ２０の制御部２１は、業務ステップ毎の所要期間の算出処理を実行する（ステップＳ１０−３）。各業務ステップに含まれる承認者を特定し、猶予期間テーブルを用いて各承認者の猶予期間を算出する。そして、申請管理手段２１４は、業務ステップ毎に猶予期間を合計して、業務ステップ毎の所要期間を算出する。

次に、承認管理サーバ２０の制御部２１は、業務プロセスのクリティカルパスの特定処理を実行する（ステップＳ１０−４）。具体的には、制御部２１の申請管理手段２１４は、ドキュメント登録画面６１１のプロパティにおいて、「前のステップ」が共通する業務ステップを特定する。そして、申請管理手段２１４は、同じ業務ステップを利用条件とする場合には、これらの業務ステップを並行して行なわれる業務ステップ（並行業務ステップ）として特定する。そして、申請管理手段２１４は、特定した業務ステップの所要期間を比較し、所要期間が長い方をクリティカルパスとして特定する。

次に、承認管理サーバ２０の制御部２１は、クリティカルパスに含まれる承認者の承認期限の設定処理を実行する（ステップＳ１０−５）。具体的には、制御部２１の申請管理手段２１４は、特定したクリティカルパスの業務ステップに含まれる承認者の猶予期間を用いて、承認期限を算出する。そして、申請管理手段２１４は、この承認期限を個別情報記憶部２７の個別管理データ２７０に登録する。

次に、承認管理サーバ２０の制御部２１は、並行業務ステップの承認期限の設定処理を実行する（ステップＳ１０−６）。具体的には、制御部２１の申請管理手段２１４は、並行業務ステップの承認期限を、クリティカルパスの業務ステップの承認期限に合わせて、個別情報記憶部２７の個別管理データ２７０に設定する。

次に、承認管理サーバ２０の制御部２１は、ステップＳ３−４と同様に、最終承認予定日の算出処理を実行する（ステップＳ１０−７）。この場合には、クリティカルパスに含まれる業務ステップの猶予期間を用いて、最終承認予定日を算出する。

そして、承認管理サーバ２０の制御部２１は、ステップＳ３−６〜Ｓ３−９と同様に、期限調整が必要かどうかについての判定処理（ステップＳ１０−８）、各承認期限の登録処理（ステップＳ１０−９）、調整画面の出力処理（ステップＳ１０−１０）、調整された各承認期限の登録処理（ステップＳ１０−１１）を実行する。
これにより、クリティカルパスを考慮して、承認期限を設定することができる。

・ 上記実施形態では、進捗一覧管理処理において、作業待ちの承認予定リストを表示する。これに加えて、承認期限までに時間的余裕がない場合には、承認者に対して注意喚起するようにしてもよい。この場合には、承認者の電子メールアドレスに対して、注意喚起のメッセージを送信する。この承認期限の確認処理を、図２０を用いて説明する。

ここでは、まず、承認管理サーバ２０の制御部２１は、期限切迫ジョブの抽出処理を実行する（ステップＳ１１−１）。具体的には、制御部２１の承認管理手段２１５は、システムタイマから現在日時を取得する。次に、承認管理手段２１５は、個別情報記憶部２７に記録されている個別管理データ２７０を用いて、各申請について、承認期限と現在日時とを比較する。そして、承認管理手段２１５は、現在日時から承認期限までの時間的余裕が基準値以下の場合には、期限切迫ジョブとして抽出する。

次に、承認管理サーバ２０の制御部２１は、期限切迫ジョブがあるかどうかについての判定処理を実行する（ステップＳ１１−２）。具体的には、制御部２１の承認管理手段２１５は、現在日時から承認期限までの時間的余裕が基準値以下の申請を特定した場合には期限切迫ジョブがあると判定する。

期限切迫ジョブがないと判定した場合（ステップＳ１１−２において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、承認期限の確認処理を終了する。
一方、期限切迫ジョブがあると判定した場合（ステップＳ１１−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、メール送信処理を実行する（ステップＳ１１−３）。具体的には、制御部２１の承認管理手段２１５は、期限切迫ジョブの承認者のメールアドレスをユーザ記憶部２３から取得する。そして、承認管理手段２１５は、このメールアドレスに対して、期限切迫ジョブがあることを通知するための電子メールを送信する。

そして、以下の処理を、期限切迫ジョブ毎に繰り返す。
承認管理サーバ２０の制御部２１は、待機処理を実行する（ステップＳ１１−４）。具体的には、制御部２１の承認管理手段２１５は、電子メールを送信してから所定の期間、待機する。ここで、承認者のクライアント端末１０において、期限切迫ジョブがあることを通知するための電子メールを受信し、承認者は電子メールを開封する。この場合には、クライアント端末１０は、開封通知を承認管理サーバ２０に送信する。開封通知を受信した承認管理サーバ２０の制御部２１は、期限切迫ジョブのジョブＩＤ、ドキュメントＩＤに関連付けて、個別情報記憶部２７の個別管理データ２７０に受信確認情報を記録する。

次に、承認管理サーバ２０の制御部２１は、受信確認済みかどうかについての判定処理を実行する（ステップＳ１１−５）。具体的には、制御部２１の承認管理手段２１５は、個別情報記憶部２７の個別管理データ２７０に受信確認情報が登録されている場合には受信確認済みと判定する。

受信確認済みと判定した場合（ステップＳ１１−５において「ＹＥＳ」の場合）、この期限切迫ジョブについての処理を終了する。
一方、受信確認済みでないと判定した場合（ステップＳ１１−５において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、他の連絡方法の特定処理を実行する（ステップＳ１１−６）。具体的には、制御部２１の承認管理手段２１５は、ディレクトリ管理サーバ４０から、この承認者の従業員コードに関連付けられた他の連絡先情報を取得する。

次に、承認管理サーバ２０の制御部２１は、連絡処理を実行する（ステップＳ１１−７）。具体的には、制御部２１の承認管理手段２１５は、取得した他の連絡先情報を用いて、期限切迫ジョブがあることを示すメッセージを送信する。
これにより、期限切迫ジョブについて、承認を促すことができる。

また、メール送信処理（ステップＳ１１−３）に加えて、このような電子メールを、複数回、送信するようにしてもよい。例えば、承認期限前だけではなく、承認期限経過後の所定時期に送信する。また、承認期限前や承認期限経過後に、それぞれ、複数回、電子メールを送信するようにしてもよい。この場合には、設定情報記憶部２２に記録されたメール設定情報に、電子メールの送信タイミングを記録しておく。

また、送信タイミングに応じて、送信内容、宛先や送信設定を変更するようにしてもよい。この場合にも、設定情報記憶部２２において、メール設定情報に、送信タイミングに関連付けて、送信内容、宛先や送信設定を記録しておく。ここで、送信内容においては、本文やタイトルを変更する。また、宛先については、送信タイミング（例えば、再度の送信）に応じて、承認者本人だけではなく、関係者（例えば、上司や管理者）に送信するように設定しておく。この場合には、承認管理サーバ２０の制御部２１は、ユーザ記憶部２３から、承認者の所属、役職に基づいて、承認者の関係者のメールアドレスを取得する。更に、期限経過後の送信設定においては、送信タイミングに応じて、受信通知（開封通知）設定や重要度設定を行なうようにしてもよい。

・ 上記実施形態では、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ７−７）。この注意情報の出力先は、承認者のクライアント端末１０に限定されるものではなく、例えば、申請者のクライアント端末１０に出力するようにしてもよい。この場合には、承認管理サーバ２０の制御部２１が、定期的に、各種申請の承認期限と現在日付とを比較する。そして、承認管理サーバ２０の制御部２１は、承認対応ができない申請を検知した場合には、この申請の申請者の連絡先を特定して、注意喚起のための電子メールを送信する。

１０…クライアント端末、２０…承認管理サーバ、２１…制御部、２１１…設定管理手段、２１２…ユーザ認証手段、２１３…画面制御手段、２１４…申請管理手段、２１５…承認管理手段、２２…設定情報記憶部、２３…ユーザ記憶部、２４…業務プロセス記憶部、２５…回付ルート記憶部、２６…画面記憶部、２７…個別情報記憶部、４０…ディレクトリ管理サーバ。

Claims (7)

1. 管理識別子に対して、属種及び属性が関連付けられた個別管理データを記憶する個別情報記憶部と、
   クライアント端末に接続された制御部とを備えた情報管理システムであって、
   前記制御部が、
   クライアント端末の入力画面において入力された属性について属種を特定し、属種及び属性に関する情報を取得し、
   前記取得した属種及び属性に関する情報に対して管理識別子を特定し、前記管理識別子に関連付けて属種及び属性を記録した個別管理データを生成して前記個別情報記憶部に記録し、
   クライアント端末に表示画面を出力する場合には、前記表示画面の管理識別子に関連付けられ、前記表示画面に含まれる属種に対応する属性を前記個別情報記憶部から取得し、
   前記属性を前記属種に対応させて設定した表示画面を生成し、前記クライアント端末に出力することを特徴とする情報管理システム。
2. 入力画面を作成するための作業画面を出力する設定管理手段を備え、
   前記設定管理手段が、前記作業画面において、管理識別子に関連付けられた入力画面のレイアウトを設定するとともに、
   前記レイアウトに含まれる入力欄に対して属種を関連づけて記録することにより、前記入力画面において入力された属性の属種を特定することを特徴とする請求項１に記載の情報管理システム。
3. 前記入力画面は、複数の業務ステップから構成された業務プロセスの一部の業務ステップにおいて、属性を入力するための画面であり、
   前記管理識別子は、前記業務プロセス及び業務ステップを特定するための情報から構成されていることを特徴とする請求項１又は２に記載の情報管理システム。
4. 前記制御部は、
   データ入力に用いる、ワークシートとフォーマットシートとからなる表計算ファイルを取得し、
   前記フォーマットシートの各フィールドに記録された属種を特定し、
   前記ワークシートにおいて、前記フォーマットシートの属種が記録されたフィールドの位置に対応するフィールドから属性を取得し、前記個別情報記憶部に記録することを特徴とする請求項１〜３のいずれか一つに記載の情報管理システム。
5. 前記制御部は、
   データ出力に用いる、ワークシートとフォーマットシートとからなる表計算ファイルを特定し、
   前記フォーマットシートの各フィールドに記録された属種を特定し、
   前記個別情報記憶部から、前記特定した属種に対応する属性を抽出し、
   前記ワークシートにおいて、フォーマットシートに記録された属種のフィールドの位置に対応するフィールドに前記属性を設定することにより、出力帳票を作成することを特徴とする請求項１〜４のいずれか一つに記載の情報管理システム。
6. 管理識別子に対して、属種及び属性が関連付けられた個別管理データを記憶する個別情報記憶部と、
   クライアント端末に接続された制御部とを備えた情報管理システムを用いて、情報を管理するための方法であって、
   前記制御部が、
   クライアント端末の入力画面において入力された属性について属種を特定し、属種及び属性に関する情報を取得し、
   前記取得した属種及び属性に関する情報に対して管理識別子を特定し、前記管理識別子に関連付けて属種及び属性を記録した個別管理データを生成して前記個別情報記憶部に記録し、
   クライアント端末に表示画面を出力する場合には、前記表示画面の管理識別子に関連付けられ、前記表示画面に含まれる属種に対応する属性を前記個別情報記憶部から取得し、
   前記属性を前記属種に対応させて設定した表示画面を生成し、前記クライアント端末に出力することを特徴とする情報管理方法。
7. 管理識別子に対して、属種及び属性が関連付けられた個別管理データを記憶する個別情報記憶部と、
   クライアント端末に接続された制御部とを備えた情報管理システムを用いて、情報を管理するためのプログラムであって、
   前記制御部を、
   クライアント端末の入力画面において入力された属性について属種を特定し、属種及び属性に関する情報を取得し、
   前記取得した属種及び属性に関する情報に対して管理識別子を特定し、前記管理識別子に関連付けて属種及び属性を記録した個別管理データを生成して前記個別情報記憶部に記録し、
   クライアント端末に表示画面を出力する場合には、前記表示画面の管理識別子に関連付けられ、前記表示画面に含まれる属種に対応する属性を前記個別情報記憶部から取得し、
   前記属性を前記属種に対応させて設定した表示画面を生成し、前記クライアント端末に出力する手段として機能させることを特徴とする情報管理プログラム。