JP2015108895A - 文書回付システム、文書回付方法及び文書回付プログラム - Google Patents

Abstract

【課題】承認等の確認処理のために申請された文書の回付を的確に管理するための文書回付システム、文書回付方法及び文書回付プログラムを提供する。
【解決手段】承認管理サーバ２０の制御部２１は、異動情報の取得処理を実行する。そして、回付先に属性変更の異動者が含まれると判定した場合、制御部２１は、停止判定処理を実行する。ここで、停止条件に該当すると判定した場合、制御部２１は、ドキュメントの回付を停止するとともに、承認者の割当を解除する。更に、制御部２１は、権限確認処理を実行する。ここでは、異動日とデータ更新日との間のドキュメントを検索し、確認属性が適切かどうかについて判定する。また、制御部２１は、再開判定処理において、回付停止のドキュメントについて、回付先を再割当し、回付を再開する。
【選択図】図１

Description

本発明は、承認等の確認処理のために申請された文書の回付を管理するための文書回付システム、文書回付方法及び文書回付プログラムに関する。

企業等の組織内における承認処理において電子ワークフローシステムが利用されることがある。この電子ワークフローシステムにおいては、申請者により作成された各種申請が、ネットワークを介して電子的に回付され、承認可否についての確認作業が行なわれている。

そこで、伝票等の紙文書を利用しながら、効率的かつ確実に承認処理を支援するための承認支援システムが検討されている（例えば、特許文献１参照）。この文献に記載された承認支援システムの承認支援サーバは、起案処理において、伝票印刷処理を実行する。この証憑台紙には、伝票コード、登録日時をコード化したバーコードが印字される。そして、承認処理において、制御部は、バーコードデータを取得し、伝票レコードの登録日時と、バーコードから取得した日時とを比較する。両者が一致した場合、承認登録処理を行なう。

また、作業対象システムについての作業申請や、作業内容の的確性についての判断を効率的に行なうための作業申請管理システムが検討されている（例えば、特許文献２参照）。この文献に記載された作業申請管理システムにおいては、承認管理サーバの制御部は、申請処理において、申請書の雛形をクライアント端末に提供する。また、作業実績確認処理において、制御部は、作業実績と作業申請との不整合の有無を判定し、作業後処理において、作業結果と申請内容とを比較する。

特開２００８−９７７２号公報（第１頁、図１） 特開２０１１−２１５７２６号公報（第１頁、図１）

しかしながら、従来のワークフロー管理においては、個々の業務ステップ単位で申請から最終承認される回付処理のみであり、個々の業務ステップに所定の関係性を持たせて束ねた業務プロセスの回付処理については考慮されていなかった。また、確認者や承認者が、回付中に異動する場合がある。この場合、そのまま回付したのでは、適切な権限者による確認や承認を実行できないことがある。特に、権限を有していないユーザによる確認や承認に基づいて手続を継続した場合、手続のやり直し等が生じ、円滑な承認管理を行なうことができない。

本発明は、上記課題を解決するためになされたものであり、承認等の確認処理のために申請された文書の回付を的確に管理するための文書回付システム、文書回付方法及び文書回付プログラムを提供することにある。

上記課題を解決する文書回付システムは、ユーザの属性情報を管理するユーザ記憶部と、文書の回付先を決定する回付先属性を記録した回付ルート記憶部と、申請された文書についての回付先を記録した文書記憶部と、前記文書の回付状態を記録した回付状態記憶部と、申請者及び回付先のクライアント端末に接続された制御部とを備える。そして、前記制御部が、前記ユーザ記憶部において属性が変更された異動ユーザを特定し、前記文書記憶部において、前記異動ユーザが、少なくとも一部に回付先として含まれている文書を特定し、前記文書における回付先において前記異動ユーザの割当を解除し、前記回付状態記憶部において、前記文書の回付について停止情報を記録し、前記回付先の割当ができないことを通知する回付停止処理を実行する。この構成によれば、回付先において異動があった文書について、申請時の回付先属性と異なる回付を停止することができる。

上記文書回付システムにおいて、停止情報が記録された文書について、前記回付ルート記憶部において回付先属性を特定し、前記ユーザ記憶部において、前記回付先属性を有するユーザを特定できた場合には、前記文書記憶部において前記文書の回付先として前記ユーザの再割当を行なう回付再開処理を実行することが好ましい。この構成によれば、新たに回付先属性を有するユーザが再割当されるので、回付先属性に応じて、文書を回付することができる。

上記文書回付システムにおいて、前記回付状態記憶部に、回付先における確認日を記録し、前記異動ユーザの異動日を特定し、文書の回付において、前記異動ユーザが確認を行なった確認日を取得し、前記異動日以降の確認日において、前記異動ユーザの異動前の属性に基づいて、確認処理が行なわれている場合には、注意喚起を出力することが好ましい。これにより、異動後に、元の回付先属性に基づいて確認処理が行なわれた文書について注意を喚起することができる。

本発明によれば、承認等の確認処理のために申請された文書の回付を的確に管理することができる。

本発明の実施形態のシステム概略図。 本実施形態の業務プロセスと業務ステップとの関係の説明図。 本実施形態の業務プロセスの具体例の説明図。 本実施形態で用いるデータの説明図であって、（ａ）はユーザ記憶部、（ｂ）は業務プロセス記憶部、（ｃ）は回付ルート記憶部に記録されたデータの説明図。 本実施形態の画面遷移の説明図。 本実施形態で用いるデータの説明図であって、（ａ）は画面記憶部、（ｂ）はドキュメント記憶部、（ｃ）は回付状態記憶部に記録されたデータの説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。

以下、図１〜図１２に従って、本発明を具体化した一実施形態を説明する。本実施形態では、申請者が提出した申請に係わる文書（ドキュメント）について、回付先（確認者、承認者）が行なう確認（承認）を支援するための文書回付システム、文書回付方法及び文書回付プログラムとして説明する。

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

図２に示すように、本実施形態では、一つの申請に対して、一つの業務プロセス（ジョブ）を用いて承認が行なわれる。この業務プロセスは、複数の業務ステップ（Ａ、Ｂ、Ｃ）から構成されている。

各業務ステップにおいては、申請のためのドキュメントを生成する（ステップＳ１−１）。本実施形態では、後述するように、ドキュメントに含まれる項目（属種）に対して値（属性）を設定することにより、ドキュメントを生成する。

そして、各業務ステップにおいては、回付ルートにおいて定められた回付先（部署、役職、個人）へのドキュメントの回付を行なう（ステップＳ１−２）。
そして、各業務ステップにおいて、ドキュメントの承認を行なう（ステップＳ１−３）。回付ルートにおいて、最終承認を完了した場合に、業務ステップを終了する。

複数の業務ステップからなる業務プロセスにおいては、別個独立に業務ステップを実行したり、複数の業務ステップを連携させて実行させたりすることができる。例えば、各業務ステップにおいて、先行の業務ステップが回付の開始条件として指定されている場合には、先行の業務ステップの回付状況に応じて、次の業務ステップにおいてドキュメント生成や回付が行なわれる。例えば、図２においては、業務ステップＡ、業務ステップＢ、業務ステップＣの順番で実行される。

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

次に、図１を用いて、本実施形態の文書回付システムの構成を説明する。
クライアント端末１０は、申請者や、確認者等の回付先のユーザが用いるコンピュータ端末である。申請者は、クライアント端末１０を用いて、各種申請を行なう。承認者や確認者等の回付先のユーザは、クライアント端末１０を用いて、申請内容を確認する。そして、承認者は、ドキュメントの内容を確認して、承認や否認、キャンセルの入力等を行なう。このクライアント端末１０は、図示しないディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。

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

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

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

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

承認管理サーバ２０は、申請者に登録された申請（ジョブ）の回付や承認を管理するためのサーバコンピュータである。この承認管理サーバ２０は、制御部２１、ユーザ記憶部２３、業務プロセス記憶部２４、回付ルート記憶部２５、画面記憶部２６、文書記憶部としてのドキュメント記憶部２７、回付状態記憶部２８を備えている。

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

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

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

申請管理部２１３は、申請者による申請に関するドキュメントを管理する処理を実行する。
回付管理部２１４は、確認者や承認者等の回付先へのドキュメントの回付を管理する処理を実行する。

異動管理部２１５は、ユーザの異動情報を取得し、この異動に対応したドキュメントの管理処理を実行する。本実施形態では、停止判定処理、権限確認処理を実行する。この異動管理部２１５は、ドキュメント回付の可否を判定するための停止条件テーブルを保持している。ドキュメント管理データ２７０に記録された各属性が、この停止条件に該当する場合には、ドキュメントの回付を停止する。本実施形態では、「回付中」、「回付先属性指定」、「属性不一致」のすべての要素を満たすことを、停止条件として用いる。

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

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

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

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

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

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

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

登録日データ領域には、このユーザ管理レコード２３０が更新された年月日に関するデータが記録される。例えば、人事異動の異動情報に基づいて、ユーザ管理レコード２３０が更新された場合には、更新日が記録される。

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

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

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

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

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

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

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

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

画面記憶部２６には、承認管理サーバ２０の利用時に使用する画面データが記録される。この画面データは、ユーザ（管理者）によって、画面レイアウトが決定された場合に登録される。

図５に示すように、画面記憶部２６には、トップ画面６１０、ドキュメント登録画面６１１、回付開始画面６１２、台帳画面６１３、ドキュメント確認画面６１４、取り戻し画面６１５、回付進捗詳細画面６１６、承認者変更画面６１７等が記録される。

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

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

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

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

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

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

図６（ａ）に示すように、画面記憶部２６には、業務ＩＤ・ステップＩＤに関連付けられた画面データ２６０が記録されている。この画面データ２６０は、表示画面とスタイルシートとから構成されている。この表示画面とスタイルシートとは、後述するように、複数のフィールドからマトリックス状に配置されて構成されている。

表示画面においては、フィールド位置に対して、入力される属性（値）の入力欄が設けられている。

スタイルシートにおいては、フィールド位置に対して、属種及びプロパティが記録されている。
フィールド位置は、画面においてフィールドが配置されている場所を特定するための情報である。
属種は、表示画面に入力された値の項目を特定するための情報である。
プロパティは、このフィールドに入力する値の条件に関する情報である。
このように、画面データ２６０を介して、予め設定された属種と、表示画面において入力された属性（値）とが関連付けられる。

図６（ｂ）に示すように、ドキュメント記憶部２７には、申請（ジョブ）の回付に用いるドキュメントに関するドキュメント管理データ２７０が記録される。このドキュメント管理データ２７０は、申請が登録された場合に記録される。ドキュメント管理データ２７０には、管理ＩＤ、属種、属性に関するデータを含んで構成される。

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

属種データ領域には、登録された属性（値）の項目を特定するための識別子が記録される。例えば、ジョブＩＤに対する属種として、業務ＩＤ、件名、登録者、登録部署、登録日、ドキュメントＩＤ等の項目に関するデータが記録される。また、任意の属種として、申請について最終承認希望日を設定することも可能である。更に、進捗状況として、現在の業務ステップのステップＩＤ、現在の業務ステップの登録者、回付先（確認者や承認者を含む）、実行停止フラグ、各承認者の承認期限等が含まれる。例えば、ジョブＩＤ及びドキュメントＩＤに対する属種として、ドキュメントに含まれる項目が記録される。例えば、不適合に対応する業務プロセスにおけるドキュメントに含まれる項目（属種）として、障害ランク、システム名、影響度、障害内容、作業状況等の項目を含める。また、実行停止フラグには、ドキュメントの回付や回付停止を管理するためのフラグを記録する。本実施形態では、後述するように、属性として「オフ」又は「オン」のいずれかを記録することができる。

属性（値）データ領域には、属種に対して入力された情報が記録される。このデータ領域には、数値やテキスト等が記録される。ここで、実行停止フラグに対して属性「オフ」が記録されている場合には、ドキュメントの回付可能、属性「オン」が記録されている場合には、ドキュメントの回付停止を意味する。また、属種（ドキュメントに含まれる項目）に対して、属性として、このドキュメントに含まれる項目（属種）の内容が記録される。

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

図６（ｃ）に示すように、回付状態記憶部２８には、ドキュメントの回付状態を管理する回付状態管理データ２８０が記録される。この回付状態管理データ２８０は、申請が登録された場合に記録される。回付状態管理データ２８０には、管理ＩＤ、回付先、回付状態に関するデータを含んで構成される。

管理ＩＤデータ領域には、各ドキュメントを特定するための識別子（ジョブＩＤ及びドキュメントＩＤ）に関するデータが記録される。
回付先データ領域には、このドキュメントの回付先に関するデータが記録される。本実施形態では、回付先である確認者や承認者のユーザＩＤが記録される。

回付状態データ領域には、このドキュメントの状態を特定するためのフラグ（未了、作業待ち、承認済、連絡済、配付済、回付停止等）が記録される。更に、各回付状態として、登録者（確認者や承認者等）、登録日（確認や承認が行われた年月日等）に関するデータが記録される。

（全体の概要）
次に、図２を用いて、全体の概要を説明する。ここでは、業務ステップＡ，Ｂ，Ｃを順番に行なう業務プロセスを想定する。
業務ステップＡにおいて、申請のためのドキュメントを登録する場合には、申請者は、クライアント端末１０を用いて、承認管理サーバ２０にアクセスする。そして、ユーザ認証を行なった後で、トップ画面６１０の作業選択において新規登録を指示する。

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

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

また、申請についての確認や承認を行なう場合、回付先のクライアント端末１０を用いて、承認管理サーバ２０にアクセスして、ユーザ認証を行なう。
そして、承認管理サーバ２０の制御部２１は、ドキュメント回付処理（ステップＳ１−２）やドキュメント承認処理（ステップＳ１−３）を実行する。具体的には、制御部２１の回付管理部２１４は、トップ画面６１０に、ドキュメント記憶部２７に記録されたジョブの進捗管理一覧を表示する。そして、処理対象の申請が選択された場合、ドキュメント確認画面６１４において設定された各属種、属性と、ドキュメント記憶部２７に記録されたドキュメント管理データ２７０との組み合わせに基づいて、ドキュメントの閲覧や入力を制御する。

次に、承認管理サーバ２０の制御部２１は、図７において後述するように、進捗の更新処理を実行する。
このように、各業務ステップＡ，Ｂ，Ｃにおいて、上述の処理（ステップＳ１−１〜Ｓ１−３）が行なわれることにより、業務プロセスを実施する。

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

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

ユーザ認証を完了した場合、承認管理サーバ２０の制御部２１は、進捗一覧表示処理を実行する（ステップＳ２−２）。具体的には、制御部２１の画面制御部２１２は、ドキュメント記憶部２７において、認証されたユーザのユーザＩＤが確認者や承認者として登録されているドキュメント管理データ２７０を抽出する。そして、画面制御部２１２は、抽出したドキュメント管理データ２７０に記録されている管理ＩＤを特定する。次に、画面制御部２１２は、抽出したドキュメント管理データ２７０を一覧表示させた作業予定リストを作成する。この作業予定リストにおいて、ドキュメント管理データ２７０を用いて、申請の進捗状況を表示させる。なお、実行停止フラグがオンになっている場合には、回付を停止中であることを示すメッセージを含める。

更に、画面制御部２１２は、抽出したドキュメント管理データ２７０を用いて、このユーザにおける作業待ちとなっている各ジョブの承認期限を特定する。そして、画面制御部２１２は、承認予定リストにおいて、承認期限が近いものから、ジョブを順番に並び替える。そして、画面制御部２１２は、トップ画面６１０において、作成した作業予定リストを「作業待ち」として出力する。

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

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

ここで、利用条件が設定されている場合、画面制御部２１２は、このジョブＩＤにおいて、先行のステップＩＤの業務ステップの状態をドキュメント記憶部２７において特定する。そして、画面制御部２１２は、特定した先行の業務ステップの状態が利用条件に一致する場合には、選択された業務ステップの画面を利用可能とする。なお、利用条件に一致しない場合には、画面制御部２１２は、この業務ステップの処理を拒否する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（ユーザ情報更新時処理）
次に、図９を用いて、ユーザ情報更新時処理を説明する。この処理は、ユーザ記憶部２３のユーザ管理レコード２３０が更新された場合に実行される。人事異動により、ユーザの属性が変更された場合、ディレクトリ管理サーバ４０のユーザデータベースが更新される。

そして、承認管理サーバ２０の制御部２１は、異動情報の取得処理を実行する（ステップＳ４−１）。具体的には、制御部２１の異動管理部２１５は、ディレクトリ管理サーバ４０から、ユーザの異動情報を取得する。この異動情報には、異動日、異動者のユーザＩＤ、異動先の部署や役職に関する情報が含まれる。そして、異動管理部２１５は、取得した異動情報に基づいて、ユーザ記憶部２３のユーザ管理レコード２３０を更新する。

次に、承認管理サーバ２０の制御部２１は、属性変更の異動者が含まれるかどうかについての判定処理を実行する（ステップＳ４−２）。具体的には、制御部２１の異動管理部２１５は、異動情報において、所属部署や役職が変更されている異動者が含まれるかどうかについて確認する。

ここで、属性変更の異動者が含まれると判定した場合（ステップＳ４−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、属性変更の異動者毎に、以下の処理を繰り返す。

ここでは、まず、承認管理サーバ２０の制御部２１は、停止判定処理を実行する（ステップＳ４−３）。この処理については、図１０を用いて後述する。
次に、承認管理サーバ２０の制御部２１は、権限確認処理を実行する（ステップＳ４−４）。この処理については、図１１を用いて後述する。

そして、すべての属性変更の異動者に対する繰り返し処理を終了した場合や、属性変更の異動者が含まれないと判定した場合（ステップＳ４−２において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、再開判定処理を実行する（ステップＳ４−５）。この処理については、図１２を用いて後述する。

（停止判定処理）
次に、図１０を用いて、停止判定処理（ステップＳ４−３）を説明する。
まず、承認管理サーバ２０の制御部２１は、ドキュメント検索処理を実行する（ステップＳ５−１）。具体的には、制御部２１の異動管理部２１５は、属性変更された異動者が回付先として登録されている回付状態管理データ２８０を回付状態記憶部２８において検索する。

次に、承認管理サーバ２０の制御部２１は、異動者に関連するドキュメントがあるかどうかについての判定処理を実行する（ステップＳ５−２）。具体的には、制御部２１の異動管理部２１５は、回付状態記憶部２８において、異動者が回付先として登録されている回付状態管理データ２８０を抽出した場合には、異動者に関連するドキュメントがあると判定する。

ここで、異動者が回付先として登録されている回付状態管理データ２８０を抽出できず、異動者に関連するドキュメントがないと判定した場合（ステップＳ５−２において「ＮＯ」の場合）、停止判定処理を終了する。

一方、異動者に関連するドキュメントがあると判定した場合（ステップＳ５−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、異動者に関連するドキュメント毎に、以下の処理を繰り返す。

ここでは、承認管理サーバ２０の制御部２１は、停止条件に該当するかどうかについての判定処理を実行する（ステップＳ５−３）。具体的には、制御部２１の異動管理部２１５は、停止条件テーブルに記録された停止条件と、このドキュメントの属性とを照合する。ここでは、停止条件として、「回付中」、「回付先属性指定」、「属性不一致」のすべての要素を満たすかどうかを確認する。

「回付中」については、異動管理部２１５は、回付状態管理データ２８０の回付状態に基づいて判定する。具体的には、回付状態として「未了」が記録されている場合には、「回付中」と判定する。

また、「回付先属性指定」については、異動管理部２１５は、回付ルート記憶部２５の回付ルート管理レコード２５０に基づいて判定する。具体的には、この回付状態管理データ２８０の管理ＩＤを構成する業務ＩＤ、ステップＩＤが記録された回付ルート管理レコード２５０を、回付ルート記憶部２５において特定する。そして、回付ルート管理レコード２５０に記録された回付先情報において、部署や役職が指定されている場合には「回付先属性指定」と判定する。

「属性不一致」については、異動管理部２１５は、回付ルート記憶部２５の回付ルート管理レコード２５０に基づいて判定する。具体的には、回付ルート管理レコード２５０において指定されている回付先情報（部署や役職）が、異動者の部署や役職とは異なる場合には「属性不一致」と判定する。
停止条件に該当しないと判定した場合（ステップＳ５−３において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、このドキュメントについての処理を終了する。

一方、停止条件に該当すると判定した場合（ステップＳ５−３において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、実行停止フラグの設定処理を実行する（ステップＳ５−４）。具体的には、制御部２１の異動管理部２１５は、ドキュメント記憶部２７のドキュメント管理データ２７０において実行停止フラグデータ領域にオンを記録する。更に、異動管理部２１５は、回付状態記憶部２８の回付状態管理データ２８０に回付状態として回付停止を記録する。

次に、承認管理サーバ２０の制御部２１は、割当解除処理を実行する（ステップＳ５−５）。具体的には、制御部２１の異動管理部２１５は、回付状態管理データ２８０に記録された回付先から異動者の割当を削除する。
以上の処理を、ドキュメント毎の処理を繰り返す。

（権限確認処理）
次に、図１１を用いて、権限確認処理（ステップＳ４−４）を説明する。この処理においては、異動者に関連するドキュメントにおける確認や承認における権限の妥当性を確認する。

まず、承認管理サーバ２０の制御部２１は、ドキュメント検索処理を実行する（ステップＳ６−１）。具体的には、制御部２１の異動管理部２１５は、属性変更された異動者が回付先として登録されている回付状態管理データ２８０を回付状態記憶部２８において検索する。

次に、承認管理サーバ２０の制御部２１は、異動者に関連するドキュメントがあるかどうかについての判定処理を実行する（ステップＳ６−２）。具体的には、制御部２１の異動管理部２１５は、回付状態記憶部２８において、異動者が回付先として登録されている回付状態管理データ２８０を抽出した場合には、異動者に関連するドキュメントがあると判定する。

ここで、異動者が回付先として登録されている回付状態管理データ２８０を抽出できず、異動者に関連するドキュメントがないと判定した場合（ステップＳ６−２において「ＮＯ」の場合）、停止判定処理を終了する。

一方、異動者に関連するドキュメントがあると判定した場合（ステップＳ６−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、異動者の異動日とデータ更新日の特定処理を実行する（ステップＳ６−３）。具体的には、制御部２１の異動管理部２１５は、異動情報に含まれる異動日を取得する。更に、異動管理部２１５は、ユーザ情報更新時（当日）をデータ更新日として取得する。

次に、承認管理サーバ２０の制御部２１は、異動日とデータ更新日との間のドキュメントの検索処理を実行する（ステップＳ６−４）。具体的には、制御部２１の異動管理部２１５は、異動情報において特定した異動日とデータ更新日との間に、回付状態の登録日が記録されている回付状態管理データ２８０（ドキュメント）を検索する。

次に、承認管理サーバ２０の制御部２１は、このドキュメントの確認属性の特定処理を実行する（ステップＳ６−５）。具体的には、制御部２１の異動管理部２１５は、特定した回付状態管理データ２８０の管理ＩＤを構成する業務ＩＤ、ステップＩＤが記録された回付ルート管理レコード２５０を回付ルート記憶部２５から抽出する。そして、異動管理部２１５は、回付ルート管理レコード２５０において指定されている回付先情報（部署や役職）を確認属性として特定する。

次に、承認管理サーバ２０の制御部２１は、確認属性が適切かどうかについての判定処理を実行する（ステップＳ６−６）。具体的には、制御部２１の異動管理部２１５は、ユーザ記憶部２３から、異動者のユーザ管理レコード２３０を取得し、現在の所属部署、役職を特定する。そして、異動管理部２１５は、回付ルート管理レコード２５０により特定した確認属性と、異動者の所属部署、役職とが一致しているかどうかを確認する。両者が一致している場合には、確認属性は適切と判定する。

確認属性は適切と判定した場合（ステップＳ６−６において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、権限確認処理を終了する。
一方、確認属性が適切でないと判定した場合（ステップＳ６−６において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ６−７）。具体的には、制御部２１の異動管理部２１５は、申請者のクライアント端末１０に対して、注意喚起メッセージを出力する。この注意喚起メッセージには、ドキュメントを特定するための管理ＩＤを含める。

（再開判定処理）
次に、図１２を用いて、再開判定処理（ステップＳ４−５）を説明する。この処理においては、回付を停止していたドキュメントについて、回付の再開可否を判定する。

まず、承認管理サーバ２０の制御部２１は、回付停止のドキュメントの検索処理を実行する（ステップＳ７−１）。具体的には、制御部２１の回付管理部２１４は、回付状態記憶部２８において、回付状態として回付停止が記録されている回付状態管理データ２８０を検索する。

次に、承認管理サーバ２０の制御部２１は、回付停止中のドキュメントがあるかどうかについての判定処理を実行する（ステップＳ７−２）。具体的には、制御部２１の回付管理部２１４は、回付状態記憶部２８において、回付停止が記録されている回付状態管理データ２８０を抽出した場合には、回付停止中のドキュメントがあると判定する。

ここで、回付停止中のドキュメントがないと判定した場合（ステップＳ７−２において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、再開判定処理を終了する。
一方、回付停止中のドキュメントがあると判定した場合（ステップＳ７−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、回付停止中のドキュメント毎に、以下の処理を繰り返す。

まず、承認管理サーバ２０の制御部２１は、再割当対象者の検索処理を実行する（ステップＳ７−３）。具体的には、制御部２１の回付管理部２１４は、回付停止中のドキュメント管理データ２７０の業務ＩＤ、ステップＩＤが記録された回付ルート管理レコード２５０を、回付ルート記憶部２５において特定する。次に、回付管理部２１４は、回付ルート管理レコード２５０に記録された回付先情報において、部署や役職を特定する。そして、回付管理部２１４は、特定した部署や役職のユーザ（確認属性を有するユーザ）を、ユーザ記憶部２３において検索する。

次に、承認管理サーバ２０の制御部２１は、再割当可能かどうかについての判定処理を実行する（ステップＳ７−４）。具体的には、制御部２１の回付管理部２１４は、確認属性を有するユーザの有無により、再割当の可否を判定する。ここで、ユーザ記憶部２３において、確認属性を有するユーザを特定できた場合、再割当可能と判定する。

ここで、再割当可能でないと判定した場合（ステップＳ７−４において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ７−５）。具体的には、制御部２１の回付管理部２１４は、申請者のクライアント端末１０に回付先がないことを含めたメッセージを出力する。そして、回付停止中のドキュメントについての処理を終了する。

一方、再割当可能と判定した場合（ステップＳ７−４において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、再割当処理を実行する（ステップＳ７−６）。具体的には、制御部２１の回付管理部２１４は、確認属性を有するユーザのユーザＩＤを、回付状態管理データ２８０に記録する。

次に、承認管理サーバ２０の制御部２１は、実行停止フラグの解除処理を実行する（ステップＳ７−７）。具体的には、制御部２１の回付管理部２１４は、ドキュメント管理データ２７０の実行停止フラグデータ領域にオフを記録する。更に、回付管理部２１４は、回付状態記憶部２８の回付状態管理データ２８０に回付状態として回付中を記録する。
以上の処理をすべての回付停止中のドキュメントについて繰り返す。

本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、承認管理サーバ２０の制御部２１は、停止判定処理を実行する（ステップＳ４−３）。ここでは、承認管理サーバ２０の制御部２１は、ドキュメント検索処理を実行する（ステップＳ５−１）。これにより、属性変更された異動者が回付先として登録されているドキュメントを特定することができる。

また、承認管理サーバ２０の制御部２１は、停止条件に該当するかどうかについての判定処理を実行する（ステップＳ５−３）。ここで、停止条件として、「回付中」を確認する。これにより、「回付中」のドキュメントを特定することができる。

また、承認管理サーバ２０の制御部２１は、停止条件に該当するかどうかについての判定処理を実行する（ステップＳ５−３）。ここで、停止条件として、「回付先属性指定」を確認する。これにより、「回付先属性指定」のドキュメントを特定することができる。

また、承認管理サーバ２０の制御部２１は、停止条件に該当するかどうかについての判定処理を実行する（ステップＳ５−３）。ここで、停止条件として、「属性不一致」を確認する。これにより、「属性不一致」のドキュメントを特定することができる。

（２）本実施形態では、停止条件に該当すると判定した場合（ステップＳ５−３において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、実行停止フラグの設定処理を実行する（ステップＳ５−４）。これにより、ドキュメントの回付を停止することができる。

（３）本実施形態では、承認管理サーバ２０の制御部２１は、割当解除処理を実行する（ステップＳ５−５）。これにより、異動になったユーザの確認や承認を抑制することができる。

（４）本実施形態では、承認管理サーバ２０の制御部２１は、権限確認処理を実行する（ステップＳ４−４）。ここでは、承認管理サーバ２０の制御部２１は、異動日とデータ更新日との間のドキュメントの検索処理を実行する（ステップＳ６−４）。これにより、異動日からデータ更新までにタイムラグが生じた場合にも、この間に確認や承認されたドキュメントを特定することができる。

更に、承認管理サーバ２０の制御部２１は、このドキュメントの確認属性の特定処理を実行する（ステップＳ６−５）。そして、確認属性が適切でないと判定した場合（ステップＳ６−６において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ６−７）。これにより、権限上、問題がある確認について注意喚起することができる。

（５）本実施形態では、承認管理サーバ２０の制御部２１は、再開判定処理を実行する（ステップＳ４−５）。回付停止中のドキュメントがあると判定した場合（ステップＳ７−２において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、再割当対象者の検索処理を実行する（ステップＳ７−３）。再割当可能でないと判定した場合（ステップＳ７−４において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ７−５）。これにより、ユーザの異動により、ドキュメントを回付できない場合には、注意を喚起することができる。

また、再割当可能と判定した場合（ステップＳ７−４において「ＹＥＳ」の場合）、承認管理サーバ２０の制御部２１は、再割当処理を実行する（ステップＳ７−６）。これにより、新たなユーザを割り当てることができる場合には、ドキュメントの回付を再開することができる。

（６）本実施形態では、業務プロセスにおいては、複数の業務ステップから構成される。各業務ステップにおいては、回付ルートにおいて定められた部署、役職、個人への回付（連絡や承認）が行なわれる。これにより、一つの業務プロセスを複数の業務ステップから構成することにより、業務プロセスの構成の自由度を確保することができる。従って、新たな業務プロセスを、既存の業務ステップを組み合わせて、効率的に作成することができる。

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

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

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

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

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

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

なお、上記実施形態は以下のように変更してもよい。
・上記実施形態では、ユーザ情報更新時処理において、停止判定処理（ステップＳ４−３）、権限確認処理（ステップＳ４−４）、再開判定処理（ステップＳ４−５）を実行する。ここで、各処理を、異なるタイミングで行なうようにしてもよい。

・上記実施形態では、承認管理サーバ２０の制御部２１は、期限調整が必要かどうかについての判定処理を実行する（ステップＳ３−６）。ここで、再開判定処理（ステップＳ４−５）において、最終承認予定日の算出処理（ステップＳ３−４）を実行し、期限調整の要否を判定するようにしてもよい。この場合には、再割当を行なったユーザの役職及び再割当を行なった時期に基づいて、最終承認予定日を算出する。そして、申請管理部２１３は、最終承認予定日が最終承認希望日よりも遅い場合には、注意を喚起するためのメッセージを申請者のクライアント端末１０に出力する。

・上記実施形態では、停止条件として、「回付中」、「回付先属性指定」、「属性不一致」を用いる。ここで、停止条件は、これに限定されるものではない。例えば、回付先属性指定として個人が指定されている場合にも、回付を停止するようにしてもよい。この場合には、申請時に、回付先として指定された個人が異動した場合の停止条件を設定しておく。そして、承認管理サーバ２０の制御部２１は、停止条件に基づいて、回付を停止するとともに、申請者によって、回付先が指定された場合には、回付を再開する。

・上記実施形態では、回付状態記憶部２８には、ドキュメントの回付状態を管理する回付状態管理データ２８０が記録される。ここで、ドキュメントの回付を停止した場合には、回付状態として、回付停止を示すフラグを記録する。ここで、ジョブ全体を停止したり、このドキュメントの回付のみを停止したりするようにしてもよい。この場合には、回付ルート記憶部２５において、業務ＩＤ、ステップＩＤに関連付けて、ドキュメントの回付中に異動者が生じた場合に、「ジョブ全体の停止」または「ドキュメントのみ」の停止を識別するための停止範囲情報を登録しておく。そして、異動管理部２１５は、回付ルート記憶部２５に記録された停止範囲情報に基づいて、回付状態記憶部２８に回付状態として「回付停止」を記録する。ここで、停止範囲情報において「ジョブ全体」が記録されている場合には、このジョブに関連するすべてのドキュメントの回付を停止する。一方、停止範囲情報において「ドキュメントのみ」が記録されている場合には、このドキュメントのみの回付を停止する。これにより、業務プロセス数を構成する各業務ステップの関連性に基づいて、ドキュメントの回付停止の要否を管理することができる。

・上記実施形態では、承認管理サーバ２０の制御部２１は、異動者の異動日とデータ更新日の特定処理を実行する（ステップＳ６−３）。具体的には、制御部２１の異動管理部２１５は、異動情報に含まれる異動日を取得する。更に、異動管理部２１５は、ユーザ情報更新時（当日）をデータ更新日として取得する。異動日やデータ更新日の特定方法は、これらに限定されるものではない。例えば、ユーザ記憶部２３に、所属部署や役職に関連付けて異動日やデータ更新日を記録し、これを用いて異動日やデータ更新日を特定するようにしてもよい。

・上記実施形態では、再割当可能でないと判定した場合（ステップＳ７−４において「ＮＯ」の場合）、承認管理サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ７−５）。具体的には、制御部２１の回付管理部２１４は、申請者のクライアント端末１０に回付先がないことを含めたメッセージを出力する。ここで、再割当可能と判定した場合（ステップＳ７−４において「ＹＥＳ」の場合）にも、承認管理サーバ２０の制御部２１は、注意喚起処理を実行するようにしてもよい。この場合には、回付管理部２１４は、申請者のクライアント端末１０に、再割当についてのメッセージ（例えば、再割当した回付先等を含める）を出力する。

１０…クライアント端末、２０…承認管理サーバ、２１…制御部、２１１…ユーザ管理部、２１２…画面制御部、２１３…申請管理部、２１４…回付管理部、２１５…異動管理部、２３…ユーザ記憶部、２４…業務プロセス記憶部、２５…回付ルート記憶部、２６…画面記憶部、２７…ドキュメント記憶部、２８…回付状態記憶部、４０…ディレクトリ管理サーバ。

Claims (5)

1. ユーザの属性情報を管理するユーザ記憶部と、
   文書の回付先を決定する回付先属性を記録した回付ルート記憶部と、
   申請された文書についての回付先を記録した文書記憶部と、
   前記文書の回付状態を記録した回付状態記憶部と、
   申請者及び回付先のクライアント端末に接続された制御部とを備えた文書回付システムであって、
   前記制御部が、
   前記ユーザ記憶部において属性が変更された異動ユーザを特定し、
   前記文書記憶部において、前記異動ユーザが、少なくとも一部に回付先として含まれている文書を特定し、前記文書における回付先において前記異動ユーザの割当を解除し、前記回付状態記憶部において、前記文書の回付について停止情報を記録し、前記回付先の割当ができないことを通知する回付停止処理を実行することを特徴とする文書回付システム。
2. 停止情報が記録された文書について、前記回付ルート記憶部において回付先属性を特定し、前記ユーザ記憶部において、前記回付先属性を有するユーザを特定できた場合には、前記文書記憶部において前記文書の回付先として前記ユーザの再割当を行なう回付再開処理を実行することを特徴とする請求項１に記載の文書回付システム。
3. 前記回付状態記憶部に、回付先における確認日を記録し、
   前記異動ユーザの異動日を特定し、
   文書の回付において、前記異動ユーザが確認を行なった確認日を取得し、
   前記異動日以降の確認日において、前記異動ユーザの異動前の属性に基づいて、確認処理が行なわれている場合には、注意喚起を出力することを特徴とする請求項１又は２に記載の文書回付システム。
4. ユーザの属性情報を管理するユーザ記憶部と、
   文書の回付先を決定する回付先属性を記録した回付ルート記憶部と、
   申請された文書についての回付先を記録した文書記憶部と、
   前記文書の回付状態を記録した回付状態記憶部と、
   申請者及び回付先のクライアント端末に接続された制御部とを備えた文書回付システムを用いて、承認を管理するための方法であって、
   前記制御部が、
   前記ユーザ記憶部において属性が変更された異動ユーザを特定し、
   前記文書記憶部において、前記異動ユーザが、少なくとも一部に回付先として含まれている文書を特定し、前記文書における回付先において前記異動ユーザの割当を解除し、前記回付状態記憶部において、前記文書の回付について停止情報を記録し、前記回付先の割当ができないことを通知する回付停止処理を実行することを特徴とする文書回付方法。
5. ユーザの属性情報を管理するユーザ記憶部と、
   文書の回付先を決定する回付先属性を記録した回付ルート記憶部と、
   申請された文書についての回付先を記録した文書記憶部と、
   前記文書の回付状態を記録した回付状態記憶部と、
   申請者及び回付先のクライアント端末に接続された制御部とを備えた文書回付システムを用いて、承認を管理するためのプログラムであって、
   前記制御部を、
   前記ユーザ記憶部において属性が変更された異動ユーザを特定し、
   前記文書記憶部において、前記異動ユーザが、少なくとも一部に回付先として含まれている文書を特定し、前記文書における回付先において前記異動ユーザの割当を解除し、前記回付状態記憶部において、前記文書の回付について停止情報を記録し、前記回付先の割当ができないことを通知する回付停止処理を実行する手段として機能させることを特徴とする文書回付プログラム。

Images