JP2003296560A - 電子承認ワークフローシステム及び記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 承認作業を整然と行うことができる電子承認
ワークフローシステム及び記憶媒体を提供する。 【解決手段】 サーバ１１の各アプリケーション１４
が、承認を要する複数種類の帳票並びに該帳票の承認予
定者及び承認作業を登録する機能を有する。データベー
ス１４ａ〜１４ｃが、各アプリケーション１４に基づき
承認を要する複数種類の帳票及び該帳票の承認予定者を
記憶する機能を有する。承認システム１５が、データベ
ース１４ａ〜１４ｃに基づき集約した帳票の種類ごと承
認予定者ごとの承認を要する件数を記憶する機能を有す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、承認作業を電子的
に行う電子承認ワークフローシステム及び記憶媒体に関
するものである。

【０００２】

【従来の技術】従来より、承認作業を電子的に行うシス
テムとして種々のものが知られている（例えば、株式会
社東計電算ＧｒｏｕｐＷａｒｅ製品「ｅ−ｗｏｒｋｓ」
の電子承認ワークフローなど）。

【０００３】

【発明が解決しようとする課題】ところで、こうした電
子承認ワークフローシステムにおいては、承認を求める
人（承認者）の端末へと個別に承認依頼の通知が送られ
る。例えば、多数の文書の種類ごとに個別のアプリケー
ションにおいて起案文書（承認を要する電子文書）が作
成・登録される場合、これに伴いそれぞれに発生する承
認依頼の通知は全て個別に送られる。従って、承認者の
端末において多数の承認依頼の通知が氾濫することにな
る。

【０００４】本発明の目的は、承認作業を整然と行うこ
とができる電子承認ワークフローシステム及び記憶媒体
を提供することにある。

【０００５】

【課題を解決するための手段】上記問題点を解決するた
めに、請求項１に記載の発明は、コンピュータを用いて
構築される電子承認ワークフローシステムにおいて、前
記コンピュータの登録手段が、承認を要する複数種類の
電子文書並びに該電子文書の承認予定者及び承認作業を
登録する機能と、同じく第１記憶手段が、前記登録手段
に基づき承認を要する複数種類の電子文書及び該電子文
書の承認予定者を記憶する機能と、同じく第２記憶手段
が、前記第１記憶手段に基づき集約した前記電子文書の
種類ごと承認予定者ごとの承認を要する件数を記憶する
機能とを備えたことを要旨とする。

【０００６】請求項２に記載の発明は、請求項１に記載
の電子承認ワークフローシステムにおいて、前記コンピ
ュータの通知手段が、前記集約した承認を要する件数を
対応する各承認予定者の端末に通知する機能を備えたこ
とを要旨とする。

【０００７】請求項３に記載の発明は、請求項２に記載
の電子承認ワークフローシステムにおいて、前記通知手
段は、前記集約した承認を要する件数を対応する各承認
予定者の端末に定期的に通知することを要旨とする。

【０００８】請求項４に記載の発明は、請求項１〜３の
いずれかに記載の電子承認ワークフローシステムにおい
て、前記登録手段は、前記電子文書の承認実施者を登録
するとともに該電子文書の承認予定者及び承認実施者が
異なる場合には代理承認として登録することを要旨とす
る。

【０００９】請求項５に記載の発明は、請求項１〜４の
いずれかに記載の電子承認ワークフローシステムにおい
て、前記登録手段及び第２記憶手段のアクセス権限は互
いに独立して設定されたことを要旨とする。

【００１０】請求項６に記載の発明は、登録された承認
を要する複数種類の電子文書及び該電子文書の承認予定
者に基づき集約した該電子文書の種類ごと承認予定者ご
との承認を要する件数を記憶する記憶媒体であることを
要旨とする。

【００１１】（作用）請求項１に記載の発明によれば、
第２記憶手段には第１記憶手段に基づき集約した電子文
書の種類ごと承認予定者ごとの承認を要する件数が記憶
されている。従って、例えば承認予定者はその端末から
第２記憶手段にアクセスすることで自らに承認が要求さ
れている電子文書の種類ごとの件数を総括的に参照する
ことができる。従って、承認予定者は自らに承認が要求
されている件数を電子文書の種類ごとに参照する必要が
ないため、承認作業を整然と行うことができる。

【００１２】請求項２又は３に記載の発明によれば、通
知手段により上記集約した承認を要する件数が対応する
各承認予定者の端末に通知される。従って、例えば承認
の要求が発生する都度に当該承認予定者の端末に通知さ
れる場合に比べて、当該通知の氾濫を抑制できる。

【００１３】請求項４に記載の発明によれば、登録手段
により電子文書の承認実施者が登録されるとともに電子
文書の承認予定者及び承認実施者が異なる場合には代理
承認として登録される。従って、電子文書の承認予定者
及び承認実施者が明確に区別され、代理承認作業を行う
ことができる。従って、緊急案件の承認にあたって代理
人による承認作業の登録が許容されることで、承認作業
を柔軟に行うことができる。

【００１４】請求項５に記載の発明によれば、登録手段
及び第２記憶手段のアクセス権限は互いに独立して設定
されている。従って、例えば代理人が第２記憶手段にア
クセスして本来の承認予定者に承認が要求されている件
数を知り得たとしても、登録手段にアクセスして承認作
業の登録をできるわけではない。これにより、代理人に
よる権限を越えた代理承認作業を防止できる。

【００１５】請求項６に記載の発明によれば、当該記憶
媒体には、登録された承認を要する複数種類の電子文書
及び電子文書の承認予定者に基づき集約した電子文書の
種類ごと承認予定者ごとの承認を要する件数が記憶され
ている。従って、例えば承認予定者はその端末から当該
記憶媒体にアクセスすることで自らに承認が要求されて
いる電子文書の種類ごとの件数を総括的に参照すること
ができる。従って、承認予定者は自らに承認が要求され
ている件数を電子文書の種類ごとに参照する必要がない
ため、承認作業を整然と行うことができる。

【００１６】

【発明の実施の形態】以下、本発明の一実施形態を図１
〜図９に従って説明する。なお、起案帳票（起案文書）
の手続き上の観点において、「承認」とは所定起案帳票
の格付けを当該部署（部門）内で同意済みの正式なもの
にすることをいう。

【００１７】図１は、本実施形態が適用される電子承認
・回覧ワークフローシステムを、特に電子承認のシステ
ムに限定して示す概略構成図である。同図に示されるよ
うに、このシステムは、サーバ１１と、通知手段を構成
するメールサーバ１２と、複数のクライアントとしての
端末１３とを備えており、これらサーバ１１、メールサ
ーバ１２及び端末１３はＬＡＮ（ローカルエリアネット
ワーク）を介して相互に接続されている。

【００１８】上記サーバ１１には、各帳票（電子文書）
の種類ごとに端末１３からのログインが許容される登録
手段を構成する複数のアプリケーション１４が格納され
ている。各アプリケーション１４は、当該種類の帳票に
係るデータ及びそのアクセス権限等の管理を行うもので
ある。具体的には、各アプリケーション１４はアクセス
権限を有する端末１３からのログインであることを条件
に、同端末１３での起案帳票（承認を要する電子文書）
の作成・登録（仮登録）、承認ルート（作成から承認に
至るまでの作成／確認／承認予定者）の設定、参照及び
確認／承認等の作業を許容する。そして、各アプリケー
ション１４は、当該種類に係る帳票のデータ（アプリケ
ーション情報）に基づく第１記憶手段を構成するデータ
ベースを構築している。

【００１９】例えば、所定の部署（部門）に属する起票
者（作成者）が、端末１３から所定種類のアプリケーシ
ョン１４にログインして当該種類の帳票を作成・登録す
るとともに当該部署内での承認ルートの設定を行うと、
これらデータは仮登録されて対応する帳票のデータベー
スに格納される。このとき、当該帳票に関連付けられて
承認・履歴情報（作成から承認に至るまでの作成／確認
／承認実行者・実行日）として作成者・作成日も上記デ
ータベースに格納される。また、確認／承認者が端末１
３から所定種類のアプリケーション１４にログイン等し
て当該種類の帳票を参照若しくは確認／承認すると、こ
れらデータも対応する帳票のデータベースに格納され
る。このとき、当該帳票に関連付けられて承認・履歴情
報として確認者・確認日、承認者・承認日も上記データ
ベースに格納される。なお、本実施形態においては、便
宜的に当該部署内における中間段階での承認を「確認」
と定義し、当該部署内における権限者による最終的な承
認を「承認」と定義してこれらを区別している。図１に
おいては、種類の異なる帳票のデータ（アプリケーショ
ン情報）のデータベースとして「工程設計総括表」、
「見積原価回答書」、「特採依頼書」の各データベース
１４ａ，１４ｂ，１４ｃを一例として示している。

【００２０】また、上記サーバ１１には、端末１３から
のログインが許容される第２記憶手段及び通知手段を構
成する承認システム１５が格納されている。この承認シ
ステム１５はアプリケーション及びデータベース等から
なり、承認・履歴情報の管理と集約・通知等を行うもの
である。具体的には、承認システム１５は、各種類ごと
の帳票のデータベース１４ａ〜１４ｃにそれぞれアクセ
スすることで各種類ごとに格納された帳票ごとの作成者
・作成日、確認者・確認日、承認者・承認日等のデータ
を入力する。そして、承認システム１５は、これらデー
タに基づき各帳票ごとに承認・履歴情報を独自に管理す
るとともに、各作成／確認／承認者（予定者）ごと各帳
票の種類ごとに作成／確認／承認を要する起案帳票の件
数をカウントすることで集約したデータ（作業一覧）を
そのデータベースに格納する。さらに、この承認システ
ム１５は、定期的（例えば、システム起動時、午前１０
時、午後３時など）に各確認／承認者（予定者）ごとの
承認依頼（メール）をメールサーバ１２に通知する。な
お、承認システム１５は、各帳票ごとに管理する承認・
履歴情報を対応する種類の帳票のデータベース１４ａ〜
１４ｃに出力するようにもなっている。従って、例えば
起票者（作成者）はその端末１３から当該種類の帳票の
データベース１４ａ〜１４ｃにアクセスすることで自分
の作成した帳票の承認・履歴情報を参照できるようにな
っている。

【００２１】上記メールサーバ１２は、サーバ１１（承
認システム１５）から通知された上記承認依頼を各対応
する確認／承認者（予定者）の端末１３に通知する。な
お、このメールサーバ１２を介して通知された承認依頼
の本文は、上記承認システム１５に格納された上記集約
されたデータ（作業一覧）を反映して作成されている。
また、この通知された承認依頼は、上記集約されたデー
タ（作業一覧）と後述の態様でリンクが張られている。
従って、確認／承認者（予定者）は、このリンクに基づ
き当該承認依頼に係るデータ（作業一覧）にアクセスす
ることで、自分に要求されている確認／承認の帳票の種
類、件数等を参照できるようになっている。また、この
ときの集約されたデータは、そのリスト内において前記
データベース１４ａ〜１４ｃに格納された帳票のデータ
（アプリケーション情報）と後述の態様でリンクが張ら
れている。従って、確認／承認者は、このリンクに基づ
き当該帳票に係るデータベース１４ａ〜１４ｃにアクセ
スすることで同帳票の参照、確認／承認の作業を行える
ようにもなっている。

【００２２】例えば、各種アプリケーション１４から作
成・登録された情報を受けると、承認システム１５はメ
ールサーバ１２を介して同作成・登録時に仮登録された
承認ルートに従って確認／承認者（予定者）に確認／承
認作業の依頼通知を発行する。このとき、この承認依頼
が依頼先（帳票の種類）ごとに集約・整理されて定期的
に通知されることはいうまでもない。従って、各確認／
承認者（予定者）には、確認／承認作業を要する件数に
関係なく１通にまとめられて通知される。いうまでもな
く、確認／承認等の作業を要する件数が０件である場合
には承認依頼が通知されることはない。

【００２３】確認／承認者（予定者）は、端末１３にお
いて承認依頼の通知を受けると、リンクに従い承認シス
テム１５にログインする（リンクに頼らず直接ログイン
してもよい）。これにより、確認／承認者は自分に要求
されている確認／承認の帳票の種類、件数等を確認し、
必要に応じて更にリンクの張られたアプリケーション１
４にログインして（リンクに頼らず直接ログインしても
よい）当該帳票（アプリケーション情報）の参照、確認
／承認の作業を行う。

【００２４】本実施形態では、当該部署内での権限者
（最終的な承認者）による最終的な承認が行われるまで
の間は後述の態様で承認ルートの変更等が随時可能とな
っており、この間において確認者（予定者）への承認依
頼の通知、確認者による帳票の参照、確認等の作業が繰
り返される。一方、承認者による承認が終了すると、確
認者（予定者）の確認の進捗に関係なく当該部署での承
認作業は終了する。

【００２５】なお、本実施形態では、確認／承認作業を
アプリケーション１４において行うため、アクセス権限
を有すれば、承認依頼の通知の有無に関わらず確認／承
認することができる。換言すると、アプリケーション１
４と承認システム１５とは互いに異なるアクセス権限に
設定されており、本来の確認／承認者（予定者）の代わ
りに代理者が承認システム１５にアクセスして当該確認
／承認者に要求されている確認／承認の帳票の種類、件
数、状態を確認することができる。ただし、代理者が本
来の確認／承認者と略同等のアプリケーション１４への
アクセス権限を有する場合にのみ、確認／承認作業を行
うことができる。この条件のもと、本来の確認／承認者
（予定者）に代わって代理の確認／承認者が後述の態様
で確認／承認作業を行うことができるようになってい
る。

【００２６】次に、この電子承認・回覧ワークフローシ
ステムにおける各作業者（作成／確認／承認者）の作業
態様について、端末１３のディスプレイでの表示画面を
併せ参照して説明する。なお、図２は、この電子承認・
回覧ワークフローシステムにおける作業者（作成／確認
／承認者）の作業態様を示す説明図である。また、図３
〜図９は、各作業結節時等における当該作業者の端末１
３のディスプレイでの表示を示す画面例である。

【００２７】図２において、起票者が当該帳票の種類に
係るアプリケーション１４にログインすると、同アプリ
ケーション１４は当該起票者の端末１３のディスプレイ
に図３のダイアログボックスからなる初期画面２０を表
示する。この初期画面２０には、当該作業の表題である
「確認・承認／ルートの設定」、当該アプリケーション
に対応して格納されるデータベースの区分（ここでは、
特採依頼書）及び同データベース内での仮の帳票番号
（データの整理番号）が表示されている。また、この初
期画面２０は、設定・処理された承認ルート及びメール
通知に応じて表示されるべき表示領域２１を有してい
る。この表示領域２１は、承認ルートにおいて代理によ
る確認／承認であるか否かを示す代理欄２１ａ、同作成
／確認／承認の順位を番号で示す承認ＳｔｅｐＮｏ．欄
２１ｂ、当該作成／確認／承認に係る担当者／仕入先名
欄２１ｃ、同作成／確認／承認を区別して示す承認処理
欄２１ｄ、作成／確認／承認が終了した場合にその日付
が表示される承認状況欄２１ｅ、作成／確認／承認にあ
たってのコメントの有無が表示されるコメント有無欄２
１ｆ、メール通知において受信側及び送信側がそれぞれ
表示されるＴｏ欄２１ｇ及びＦｒｏｍ欄２１ｈからな
る。なお、図３は初期状態であるためいずれの欄２１ａ
〜２１ｈも空欄になっている。さらに、この初期画面２
０は、承認ルートの設定等のために選択される選択領域
２２を有している。この選択領域２２は、予め登録され
た承認ルートのリストから所定承認ルートを選択させる
ための承認ルート選択ボタン２２ａ、設定された承認ル
ートに確認者を追加等させるための追加ボタン２２ｂ、
同確認／承認者を変更させるための変更ボタン２２ｃ、
同削除させるための削除ボタン２２ｄ、ログ表示（ＯＦ
Ｆ）ボタン２２ｅ、当該帳票についてコメントを挿入さ
せるためのコメントボタン２２ｆ、当該帳票について作
成／確認／承認者の了解（完了）を登録させるための了
解ボタン２２ｇ、同差戻しを登録させるための差戻しボ
タン２２ｈからなる。ここで、「追加」とは自分に加え
て誰かを確認者にすることであり、「変更」とは自分に
代えて誰かを確認／承認者にすることである。なお、図
３は初期状態であるため追加ボタン２２ｂ、変更ボタン
２２ｃ、削除ボタン２２ｄ、コメントボタン２２ｆ、了
解ボタン２２ｇ、差戻しボタン２２ｈは活性化されてい
ない（実行できない）。

【００２８】この初期画面２０において、起票者が上記
選択領域２２の承認ルート選択ボタン２２ａを当該端末
１３のポインティングデバイス（マウスなど）にてクリ
ック（選択）する。すると、上記アプリケーション１４
は同端末１３のディスプレイに予め登録された承認ルー
トのリストから所定承認ルートを選択するためのサブ画
面（図示略）を表示する。従って、起票者は、このサブ
画面において所定承認ルートを選択することで基準の承
認ルートを設定する。なお、起票者は、上記サブ画面に
おいて承認ルートの最終を指定するために中間段階では
「確認」を、最終段階では「承認」をそれぞれ区別して
設定する。このサブ画面での作業が終了すると、上記ア
プリケーション１４は当該端末１３のディスプレイに図
４（ａ）のダイアログボックスからなるサブ画面２０ａ
を表示する。このとき、承認の順位は承認ＳｔｅｐＮ
ｏ．欄２１ｂに番号で示される。また、作成／確認／承
認の区別は承認処理欄２１ｄに区別して示される。ここ
では、作成者、確認者、承認者はそれぞれ○山氏、△浦
氏、□越氏にそれぞれ設定されている。さらに、この状
態では上記追加ボタン２２ｂ、変更ボタン２２ｃ、コメ
ントボタン２２ｆ、了解ボタン２２ｇ及び差戻しボタン
２２ｇは活性化される（実行できる）。

【００２９】ここで、起票者が上記追加ボタン２２ｂを
当該端末１３のポインティングデバイスにてクリックす
る。すると、上記アプリケーション１４は同端末１３の
ディスプレイに回覧ルートで受けた帳票をそのまま他の
担当者に転送するか若しくは現状で設定されている承認
ルートに確認者を追加するかを選択するためのサブ画面
（図示略）を表示する。従って、起票者は、このサブ画
面において承認ルートに確認者を追加する選択をするこ
とで当該承認ルートに追加したい確認者を設定する。さ
らに、起票者が上記変更ボタン２２ｃを当該端末１３の
ポインティングデバイスにてクリックすると、上記アプ
リケーション１４は同端末１３のディスプレイに現状で
設定されている承認ルートの確認／承認者を変更するた
めのサブ画面（図示略）を表示する。従って、起票者
は、このサブ画面において承認ルートの確認／承認者を
変更することで当該承認ルートに変更したい確認／承認
者を設定する。この場合においても、確認／承認を区別
して設定することはいうまでもない。つまり、基本的に
起票者は、確認／承認を依頼すべき個人ごとに区別し
て、設定していく。

【００３０】このサブ画面２０ａにおいて、起票者が了
解ボタン２２ｇを当該端末１３のポインティングデバイ
スにてクリックすると、上記アプリケーション１４は起
案帳票の作成が完了したものとして承認・履歴情報とし
ての作成者・作成日を当該起案帳票に関連付けて登録す
る（図２参照）。そして、上記アプリケーション１４は
同端末１３のディスプレイに図４（ｂ）のダイアログボ
ックスからなるサブ画面２０ｂを表示する。このサブ画
面２０ｂにおいて、上記アプリケーション１４は上記承
認状況欄２１ｅに作成日を表示する。また、アプリケー
ション１４は、この起案帳票の作成完了（承認・履歴情
報）を受けて、この状態での以降の変更等を禁止すべく
上記追加ボタン２２ｂ、変更ボタン２２ｃ等を非活性化
する。そして、アプリケーション１４はこの起案帳票を
承認待ちの状態にする。

【００３１】以上の態様で複数の端末１３において複数
種類に亘って起案帳票が作成・登録等されると、各起案
帳票ごとの承認・履歴情報としての作成者・作成日等の
データが前記承認システム１５に入力される。承認シス
テム１５は、これらデータに基づき各帳票ごとに承認・
履歴情報を管理するとともに、各作成／確認／承認者ご
と各帳票の種類ごとに集約したデータ（作業一覧）を格
納する。このとき、確認／承認の要求が発生することで
承認システム１５は、設定された承認ルートに従い当該
確認／承認者（予定者）に前記メールサーバ１２を介し
て確認／承認作業の依頼通知を発行することは既述のと
おりである。

【００３２】図２に示す確認／承認者（予定者）への承
認依頼の通知において、承認システム１５はメールサー
バ１２を介して当該確認／承認者の端末１３のディスプ
レイに図５（ａ）の通知画面３０を表示する。承認依頼
の通知は要求（依頼）の発生ごとではなく定期的に送ら
れるため、１通にまとめられたものになっている。従っ
て、確認／承認者は多数の承認依頼の通知に煩わされる
ことがない。

【００３３】この通知画面３０はメール本文の表示領域
３１を有しており、当該確認／承認者に係る各帳票の種
類ごとの作業待ち件数が表示されている。この作業待ち
件数には、特に新規発生した件数を別示して各帳票の種
類ごとに全作業待ち件数が表示されている。

【００３４】また、この表示領域３１には当該作業待ち
件数に対応する作業待ち一覧（作業一覧）を表示させる
ためのリンク３１ａが表示されている。このリンク３１
ａは、当該端末１３のポインティングデバイスにてクリ
ックされることで、上記承認システム１５にアクセスし
て当該確認／承認者（メール受信者）が作成／確認／承
認を行うべき作業一覧を表示させる。すなわち、確認／
承認者がこのリンク３１ａをクリックすると、上記承認
システム１５により当該確認／承認者に対して各帳票の
種類ごとに集約されたデータ（作業一覧）が前記メール
サーバ１２を介して端末１３のディスプレイに表示され
るようになっている。

【００３５】なお、各確認／承認者がシステムにログイ
ンした際に表示される図５（ｂ）のメニュー画面３２に
おいて、承認依頼・通知ボタン３２ａをクリックして
も、同様に上記集約されたデータ（作業一覧）が表示さ
れるようになっている。

【００３６】確認／承認者が表示領域３１（通知画面３
０）のリンク３１ａをクリックし、若しくはメニュー画
面３２の承認依頼・通知ボタン３２ａをクリックする
と、当該確認／承認者の端末１３のディスプレイには図
６（ａ）のダイアログボックスからなるサブ画面３３が
表示される。このサブ画面３３には、当該確認／承認者
に対して各帳票の種類ごと状態ごとに集約されたデータ
が作業一覧３３ａとして表示されている。同図において
は、帳票の種類として特採依頼書及びライン構成検討表
が表示され、個人作業待ち、部門作業中、処理完了通知
としてそれぞれ件数が表示されている。なお、作成／確
認／承認作業を要する案件は個人作業待ちとしてその件
数が表示されている。

【００３７】上記作業一覧３３ａにおいて、各帳票の種
類ごと状態ごとに表示された件数はリンク３３ｂとして
表示されている。このリンク３３ｂは、当該端末１３の
ポインティングデバイスにてクリックされることで、上
記メールサーバ１２を介して当該帳票の種類に係るアプ
リケーション１４（データベース１４ａ〜１４ｃ）にア
クセスする。そして、図６（ｂ）に示すサブ画面３４に
おいて当該確認／承認者が作成／確認／承認を行うべき
内容を一覧で表示させる。すなわち、確認／承認者がこ
のリンク３３ｂをクリックすると、各アプリケーション
１４により当該帳票の種類ごとに格納されたデータ（確
認／承認を行うべき内容）が前記メールサーバ１２を介
して端末１３のディスプレイに内容一覧３４ａとして表
示されるようになっている。なお、承認システム１５の
承認・履歴情報はアプリケーション１４側にも入力され
ているため、当該帳票についての自らの状態が帳票状況
（ここでは、作成中）として表示されている。いうまで
もなく、アプリケーション１４はこの帳票状況（作成
中、承認中、承認済）に応じたセキュリティを確保す
る。各確認／承認者は、この内容一覧３４ａに基づきそ
の確認／承認の適否を検討する。そして、当該確認／承
認者が内容一覧３４ａの所定帳票についての確認／承認
作業を行う場合には、当該帳票の選択ボタン３４ｂを端
末１３のポインティングデバイスにてクリックし、更に
確認／承認ボタン３４ｃをクリックする。このとき、当
該アプリケーション１４は確認／承認者の端末１３のデ
ィスプレイに確認・承認／ルートの設定に係るサブ画面
（図４（ａ）参照）を表示する。確認／承認者は、この
サブ画面において追加ボタン２２ｂ、変更ボタン２２ｃ
をクリックして適宜の承認ルートの追加・変更等を行う
（図２参照）。あるいは、確認／承認者は、このサブ画
面においてコメントボタン２２ｆをクリックしてコメン
トを挿入し、了解ボタン２２ｇをクリックして確認／承
認を確定し、若しくは差戻しボタン２２ｈをクリックし
て当該帳票を差戻す。なお、このサブ画面において、確
認／承認者が了解ボタン２２ｇを当該端末１３のポイン
ティングデバイスにてクリックすると、上記アプリケー
ション１４は当該帳票の確認／承認が完了したものとし
て承認・履歴情報としての確認者・確認日、承認者・承
認日を当該起案帳票に関連付けて登録する（図２参
照）。このとき、上記アプリケーション１４は作成日
（図４（ｂ）参照）に準じて上記承認状況欄２１ｅに当
該確認／承認者の確認日／承認日を表示する。また、ア
プリケーション１４は、この帳票の確認完了（承認・履
歴情報）を受けて、この状態での以降の変更等を禁止す
べく上記追加ボタン２２ｂ、変更ボタン２２ｃ等を非活
性化する。そして、アプリケーション１４はこの帳票を
次段の承認待ちの状態に変更する。従って、上記に準じ
て承認依頼が次段の確認／承認者に通知される。若しく
は、アプリケーション１４は、権限者によるこの帳票の
最終的な承認完了（承認・履歴情報）を受けて、この状
態での以降の承認ルートの選択、変更等を禁止すべく上
記承認ルート選択ボタン２２ａ、追加ボタン２２ｂ、変
更ボタン２２ｃ等を非活性化する。すなわち、承認権限
者（承認者）が承認することで当該帳票の承認に係るワ
ークフローは終了する。

【００３８】なお、確認／承認者が確認／承認を完了す
ると、承認システム１５は当該確認／承認者のサブ画面
３３の作業一覧３３ａ（図６（ａ）参照）における個人
作業待ちの件数を減少させる。

【００３９】次に、本実施形態での起案帳票の代理確認
／承認の作業態様について説明する。既述のように本実
施形態では確認／承認作業をアプリケーション１４上で
行うため、図２に示すように権限（アクセス権限）を有
すれば承認依頼の通知の有無に関わらず当該起案帳票の
確認／承認作業をできるにようになっている。従って、
本来の承認ルート（図４参照）における確認者（予定
者）である△浦氏に代わって、同様の確認権限を有する
○垣氏がメニュー画面３２（図５（ｂ）参照）におい
て、承認依頼・通知ボタン３２ａをクリックする。する
と、上記に準じて当該確認者（代理確認者）の端末１３
のディスプレイには本来の確認者（△浦氏）に要求され
た作業一覧として図７（ａ）のサブ画面３３が表示され
る。なお、代理確認者（○垣氏）には承認依頼が通知さ
れないため、同代理確認者は確認者（△浦氏）による事
前の業務委託、あるいは作成者である○山氏の依頼と権
限者としての判断に基づき作業一覧３３ａから代理確認
すべき案件を選択して代理確認作業を行うことになる。

【００４０】代理確認者がサブ画面３３のリンク３３ｂ
をクリックすることで、上記に準じてそのディスプレイ
に内容一覧３４ａ（図６（ｂ）参照）が表示される。た
だし、この内容一覧３４ａの表示はアプリケーション１
４へのアクセスが前提になるため、アプリケーション１
４側のセキュリティの制約を受けることになる。従っ
て、この代理確認者（○垣氏）における内容一覧３４ａ
の表示は、本来の確認者（△浦氏）における内容一覧の
表示と必ずしも一致するものではなく、その委任可能な
権限の範囲で異なっている。代理確認者は、この内容一
覧３４ａに基づき上記に準じてその確認作業を行う。代
理確認者による当該帳票の確認が完了すると、アプリケ
ーション１４は上記に準じて承認・履歴情報としての代
理確認者及び確認日を当該起案帳票に関連付けて登録す
る。このとき、上記アプリケーション１４は当該端末１
３のディスプレイに図７（ｂ）のダイアログボックスか
らなるサブ画面３５を表示する。そして、上記アプリケ
ーション１４は上記承認ルートの順位に代理確認者（○
垣氏）の欄を割り込み表示し、代理欄２１ａに代理であ
ることを示すマーク（◎印）を、承認状況欄２１ｅに確
認日を表示する。なお、代理確認の処理が完了すると、
承認システム１５は本来の確認者（△浦氏）のサブ画面
３３の作業一覧３３ａにおける個人作業待ちの件数を減
少させる。

【００４１】一方、代理確認の処理が完了すると、図２
に示すように最終的な承認者である□越氏に承認依頼が
通知される。従って、承認者（□越氏）が上記に準じて
表示領域３１（通知画面３０）のリンク３１ａをクリッ
クし（図５（ａ）参照）、若しくはメニュー画面３２の
承認依頼・通知ボタン３２ａをクリックすると（図５
（ｂ）参照）、当該承認者の端末１３のディスプレイに
は図８（ａ）のサブ画面３３が表示される。

【００４２】また、本来の承認ルート（図４参照）にお
ける承認者（予定者）である□越氏に代わって、同様の
確認権限を有する△永氏がメニュー画面３２（図５
（ｂ）参照）において、承認依頼・通知ボタン３２ａを
クリックする。すると、上記に準じて当該承認者（代理
承認者）の端末１３のディスプレイには本来の確認者
（□越氏）に要求された作業一覧としてサブ画面３３
（図８（ａ）参照）が表示される。なお、代理承認者
（○垣氏）にも承認依頼が通知されないため、同代理承
認者は承認者（□越氏）による事前の業務委託、あるい
は作成者である○山氏の依頼と権限者としての判断に基
づき作業一覧３３ａから代理承認すべき案件を選択して
代理承認作業を行うことになる。

【００４３】代理承認者がサブ画面３３のリンク３３ｂ
（図８（ａ）参照）をクリックすることで、上記に準じ
てそのディスプレイに内容一覧３４ａ（図６（ｂ）参
照）が表示される。ただし、この内容一覧３４ａの表示
はアプリケーション１４へのアクセスが前提になるた
め、アプリケーション１４側のセキュリティの制約を受
けることになる。従って、この代理承認者（△永氏）に
おける内容一覧３４ａの表示も、本来の承認者（□越
氏）における内容一覧の表示と必ずしも一致するもので
はなく、その委任可能な権限の範囲で異なっている。代
理承認者は、この内容一覧３４ａに基づき上記に準じて
その承認作業を行う。代理承認者による当該帳票の承認
が完了すると、アプリケーション１４は上記に準じて承
認・履歴情報としての代理承認者及び承認日を当該起案
帳票に関連付けて登録する。このとき、上記アプリケー
ション１４は当該端末１３のディスプレイに図９のダイ
アログボックスからなるサブ画面３６を表示する。そし
て、上記アプリケーション１４は上記承認ルートの順位
に代理承認者（△永氏）の欄を加えて表示し、代理欄２
１ａに代理であることを示すマーク（◎印）を、承認状
況欄２１ｅに承認日を表示する。なお、代理承認の処理
が完了すると、承認システム１５は本来の承認者（□越
氏）のサブ画面３３の作業一覧３３ａにおける個人作業
待ちの件数を減少させる。そして、当該帳票に関しての
承認に係るワークフローが完了する。

【００４４】当該帳票の電子承認のワークフローが終了
すると、別に用意された電子回覧のシステムにおいて部
署間に亘る回覧ルート上での起票日が正式登録され、回
答／決済を要する他部署へと通知されるようになってい
る。

【００４５】以上詳述したように、本実施形態によれ
ば、以下に示す効果が得られるようになる。 （１）本実施形態では、承認システム１５にはデータベ
ース１４ａ〜１４ｃに基づき集約した帳票の種類ごと確
認／承認予定者ごとの確認／承認を要する件数が記憶さ
れている。従って、例えば確認／承認予定者はその端末
１３から承認システム１５にアクセスすることで自らに
確認／承認が要求されている帳票の種類ごとの件数を総
括的に参照することができる。従って、確認／承認予定
者は自らに確認／承認が要求されている件数を帳票の種
類ごとに参照する必要がないため、確認／承認作業を整
然と行うことができる。

【００４６】（２）本実施形態では、メールサーバ１２
を介して上記集約した確認／承認を要する件数（承認依
頼通知）が対応する各確認／承認予定者の端末１３に通
知される。従って、例えば確認／承認の要求が発生する
都度に当該確認／承認予定者の端末１３に通知される場
合に比べて、当該通知の氾濫を抑制できる。

【００４７】（３）本実施形態では、アプリケーション
１４により帳票の確認／承認実施者が登録されるととも
に帳票の確認／承認予定者及び確認／承認実施者が異な
る場合には代理確認／承認として登録される。従って、
帳票の確認／承認予定者及び確認／承認実施者が明確に
区別され、代理確認／承認作業を行うことができる。従
って、緊急案件の確認／承認にあたって代理人による確
認／承認作業の登録が許容されることで、確認／承認作
業を柔軟に行うことができる。

【００４８】（４）本実施形態では、アプリケーション
１４及び承認システム１５のアクセス権限は互いに独立
して設定されている。従って、例えば代理人が承認シス
テム１５にアクセスして本来の確認／承認予定者に確認
／承認が要求されている件数を知り得たとしても、アプ
リケーション１４にアクセスして確認／承認作業の登録
をできるわけではない。これにより、代理人による権限
を越えた代理確認／承認作業を防止できる。

【００４９】なお、本発明の実施の形態は上記実施形態
に限定されるものではなく、次のように変更してもよ
い。 ・前記実施形態においては特に言及していないが、承認
システム１５によるデータの集約（作業一覧の作成）を
承認依頼の通知に先立って定期的に行うようにしてもよ
い。

【００５０】・前記実施形態においては特に言及してい
ないが、全ての確認者による確認作業が終了する前に最
終的な承認者による承認作業を行ってもよい。この場
合、中段の確認の現状に関わらず最終的な承認が登録さ
れることで当該帳票の承認に係るワークフローが終了す
る。

【００５１】・前記実施形態においては、代理確認／承
認にあたって代理確認／承認者が承認システム１５への
アクセスにより本来の確認／承認者（予定者）の作業一
覧３３ａを表示させてその後の代理確認／承認作業を行
うようにした。これに対して、アプリケーション１４に
より各帳票のデータに関連付けて代理確認／承認者のデ
ータが登録できるようにする。そして、承認システム１
５により各帳票及び代理確認／承認者のデータに基づき
各代理確認／承認者ごと各帳票の種類ごとに代理確認／
承認を要する起案帳票の件数をカウントすることで集約
したデータ（作業一覧）をそのデータベースに格納す
る。この場合、代理確認／承認者は承認システム１５へ
のアクセスにより本来の確認／承認者（予定者）に代わ
って確認／承認可能な作業一覧を表示させてその後の代
理確認／承認作業を行うようにする。このように変更を
しても前記実施形態と同様の効果が得られる。

【００５２】・前記実施形態においては、代理確認／承
認者は、確認／承認者による事前の業務委託、あるいは
作成者の依頼と権限者としての判断に基づき代理確認作
業を行うようにした。これに対して、例えば承認システ
ム１５により各確認／承認者の勤務予定のデータを参照
できるようにする。そして、承認システム１５は、例え
ばこの確認／承認者の勤務予定と確認／承認期限との各
データを照らし合わせて確認／承認が間に合わないと判
断された場合には、メールサーバ１２を介して承認依頼
を直接代理確認／承認者に通知する。このように変更す
ることで、前記実施形態と同様の効果に加え、確認／承
認者の勤務予定に制約されて業務委託や代理の依頼が必
要になる煩わしさが解消される。

【００５３】・前記実施形態においては、クライアント
としての端末１３の構成について特に言及していない
が、入力装置（キーボード、マウスなど）及び出力装置
（ディスプレイ、プリンタなど）を備えていればよい。
いうまでのまく、汎用のパーソナルコンピュータなどで
あってもよい。

【００５４】・前記実施形態においては、サーバ１１の
内部においてアプリケーション１４及び承認システム１
５の各機能を設けた。これに対して、これらアプリケー
ション１４及び承認システム１５の各機能を、互いに独
立したサーバの内部に設けてもよい。

【００５５】・前記実施形態においては、ＬＡＮによる
ネットワークを構成したが、この接続においては専用線
を利用したり、インターネット環境を利用・応用したイ
ントラネットやエクストラネットなどとしてもよい。

【００５６】

【発明の効果】以上詳述したように、請求項１又は６に
記載の発明によれば、承認作業を整然と行うことができ
る。

【００５７】請求項２又は３に記載の発明によれば、承
認予定者の端末での承認要求の通知の氾濫を抑制でき
る。請求項４に記載の発明によれば、緊急案件の承認に
あたって代理人による承認作業の登録が許容されること
で、承認作業を柔軟に行うことができる。

【００５８】請求項５に記載の発明によれば、代理人に
よる権限を越えた代理承認作業を防止できる。

【図面の簡単な説明】

【図１】本発明の一実施形態を示すシステム構成図。

【図２】同実施形態の承認作業を示す説明図。

【図３】同実施形態の各作業結節時等における端末のデ
ィスプレイでの表示を示す画面の例図。

【図４】同実施形態の各作業結節時等における端末のデ
ィスプレイでの表示を示す画面の例図。

【図５】同実施形態の各作業結節時等における端末のデ
ィスプレイでの表示を示す画面の例図。

【図６】同実施形態の各作業結節時等における端末のデ
ィスプレイでの表示を示す画面の例図。

【図７】同実施形態の各作業結節時等における端末のデ
ィスプレイでの表示を示す画面の例図。

【図８】同実施形態の各作業結節時等における端末のデ
ィスプレイでの表示を示す画面の例図。

【図９】同実施形態の各作業結節時等における端末のデ
ィスプレイでの表示を示す画面の例図。

【符号の説明】

１１ サーバ １２ 通知手段を構成するメールサーバ １３ 端末 １４ 登録手段を構成するアプリケーション １４ａ〜１４ｃ 第１記憶手段を構成するデータベース １５ 第２記憶手段及び通知手段を構成する承認システ
ム

───────────────────────────────────────────────────── フロントページの続き (72)発明者 奥田 康晴 愛知県安城市藤井町高根10番地 アイシ ン・エィ・ダブリュ 株式会社内

Claims (6)

【特許請求の範囲】
1. 【請求項１】 コンピュータを用いて構築される電子
   承認ワークフローシステムにおいて、 前記コンピュータの登録手段が、承認を要する複数種類
   の電子文書並びに該電子文書の承認予定者及び承認作業
   を登録する機能と、 同じく第１記憶手段が、前記登録手段に基づき承認を要
   する複数種類の電子文書及び該電子文書の承認予定者を
   記憶する機能と、 同じく第２記憶手段が、前記第１記憶手段に基づき集約
   した前記電子文書の種類ごと承認予定者ごとの承認を要
   する件数を記憶する機能とを備えたことを特徴とする電
   子承認ワークフローシステム。
2. 【請求項２】 請求項１に記載の電子承認ワークフロ
   ーシステムにおいて、 前記コンピュータの通知手段が、前記集約した承認を要
   する件数を対応する各承認予定者の端末に通知する機能
   を備えたことを特徴とする電子承認ワークフローシステ
   ム。
3. 【請求項３】 請求項２に記載の電子承認ワークフロ
   ーシステムにおいて、 前記通知手段は、前記集約した承認を要する件数を対応
   する各承認予定者の端末に定期的に通知することを特徴
   とする電子承認ワークフローシステム。
4. 【請求項４】 請求項１〜３のいずれかに記載の電子
   承認ワークフローシステムにおいて、 前記登録手段は、前記電子文書の承認実施者を登録する
   とともに該電子文書の承認予定者及び承認実施者が異な
   る場合には代理承認として登録することを特徴とする電
   子承認ワークフローシステム。
5. 【請求項５】 請求項１〜４のいずれかに記載の電子
   承認ワークフローシステムにおいて、 前記登録手段及び第２記憶手段のアクセス権限は互いに
   独立して設定されたことを特徴とする電子承認ワークフ
   ローシステム。
6. 【請求項６】 登録された承認を要する複数種類の電
   子文書及び該電子文書の承認予定者に基づき集約した該
   電子文書の種類ごと承認予定者ごとの承認を要する件数
   を記憶する記憶媒体。