JP2003114963A

JP2003114963A - 決裁システム

Info

Publication number: JP2003114963A
Application number: JP2001310448A
Authority: JP
Inventors: Kazunari Yamada; 一成山田
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2001-10-05
Filing date: 2001-10-05
Publication date: 2003-04-18

Abstract

(57)【要約】【課題】それぞれが独立且つ関連した複数の組織間で
の決裁をスムースに行うことができるようにする。【解決手段】Ａ社、Ｂ社（及びＣ社）とがネットワー
クで接続される。Ａ社に置かれた決裁システムサーバ１
０６は、共通の人事・組織・電子メールアドレスＤＢ６
３、Ａ社及びＢ社の決裁ＤＢ５０Ａ及び５０Ｂ、メール
フォーマットＤＢ５２、並びに、Ａ社及びＢ社夫々の決
裁ルールに基づく回付ルートが格納された決裁回付ルー
トテーブル５１を有する。Ａ社で起案されＤＢ５０Ａに
格納された決裁申請書は、ＤＢ６３及びテーブル５１に
より各社の回付ルートが設定され、ＤＢ５２に基づきフ
ォームが自動的に生成された電子メールにＤＢ５０Ａの
格納場所がＵＲＬとして埋め込まれて、各回付ルート先
に順次送信される。回付先で決裁申請書に承認や確認が
行われ、回付ルートに従い次の回付先に回付される。決
裁申請書は、最後にＡ社の決裁者に回付され、決裁が行
われる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ネットワークを
利用して決裁を行う決裁システムに関し、特に、決裁が
それぞれ独立且つ関連した複数の組織に跨ってなされる
際に用いて好適な決裁システムに関する。

【０００２】

【従来の技術】従来では、決裁を行う行為自体は、一つ
の組織内に限定して実行され、外部の他の組織からの介
入を必要とすることがなかった。しかしながら、近年の
サプライチェーンの導入や、カンパニー制による社内分
社化、製販組織分割などにより、組織単体での決裁処理
が難しくなってきた。これらの制度の下では、各組織
は、それぞれシステム的に独立している一方で、業務が
互いに関連しているため単独では決裁ができない場合が
ある。

【０００３】

【発明が解決しようとする課題】このような場合、多く
は、電話や連絡会議などによる根回しの徹底、商慣習に
よる暗黙の了解などに頼って決裁を行っていた。この従
来の方法では、実際に決裁が下されるまでの期間が長く
かかってしまうなどの問題点があった。

【０００４】また、組織が大きくなってくると、一人で
多数の部門の長を兼ねることも珍しくない。この場合、
その一人に対し、兼務しているそれぞれの部門において
肩書きが変わることになる。そのため、各部門において
決裁権の金額ベースや人事権が変わり、さらに、決裁ル
ールまでもが変わり、扱いを混乱させてしまうという問
題点があった。

【０００５】さらに、大きな組織の長として決裁する側
にしてみれば、決裁の度に多大な時間を要するようで
は、業務進行に支障を来すおそれがあるという問題点が
あった。

【０００６】さらにまた、従来のワークフローでは、決
裁申請書の回付先の追加、変更および削除ができなかっ
た。そのため、決裁途中でその決裁の起案者が異動にな
ったような場合でも、柔軟な対応が取れないという問題
点があった。またそのため、組織が比較的短い間隔で変
更されるような場合にも、十分な対応が取れないという
問題点があった。

【０００７】したがって、この発明の目的は、それぞれ
が独立且つ関連した複数の組織間での決裁をスムースに
行うことができる決裁システムを提供することにある。

【０００８】

【課題を解決するための手段】この発明は、上述した課
題を解決するために、それぞれ独立した決裁権を有する
複数の組織に跨って決裁を行うようにした決裁システム
において、それぞれ独立した決裁権を有する複数の組織
間で通信を行うと共に、複数の組織それぞれの内部で通
信を行うネットワーク手段と、組織の人事および組織情
報、ならびに、組織に所属する者のネットワーク手段上
でのアドレス情報を、複数の組織について共通に格納す
る第１のデータベースと、複数の組織それぞれの決裁ル
ール情報を格納する第２のデータベースと、決裁情報を
格納する決裁データベースと、第１のデータベースに格
納された組織の人事および組織情報、ならびに、アドレ
ス情報と、第２のデータベースに格納された決裁ルール
情報とに基づき、決裁データベースに格納された決裁情
報の回付先を設定する決裁情報回付先設定手段と、決裁
情報回付先設定手段により設定された決裁情報の回付先
に、決裁データベースに格納された決裁情報をネットワ
ーク手段を介して回付する決済情報回付手段とを備える
ことを特徴とする決裁システムである。

【０００９】上述したように、この発明は、ネットワー
クによりそれぞれ独立した決裁権を有する複数の組織間
で通信を行うと共に、複数の組織それぞれの内部で通信
を行うようにされ、組織の人事および組織情報、ならび
に、組織に所属する者のネットワーク上でのアドレス情
報が第１のデータベースに複数の組織について共通に格
納され、第２のデータベースに複数の組織それぞれの決
裁ルール情報が格納され、決裁データベースに決裁情報
が格納され、第１のデータベースに格納された組織の人
事および組織情報、ならびに、アドレス情報と、第２の
データベースに格納された決裁ルール情報とに基づき、
決裁データベースに格納された決裁情報の回付先が設定
され、設定された決裁情報の回付先に、決裁データベー
スに格納された決裁情報をネットワークを介して回付す
るようにしているため、それぞれ独立した決裁権を有す
る複数の組織間に跨る決裁が発生しても、それぞれの組
織の決裁ルールに従い、それぞれの組織の担当者に対し
て正確なアドレス情報によりネットワークを介して決裁
情報を回付することができる。

【００１０】

【発明の実施の形態】以下、この発明の実施の一形態に
ついて説明する。先ず、理解を容易とするために、この
実施の一形態に適用可能な業務フローについて、図１を
用いて概略的に説明する。決裁が必要な案件が発生する
と、決裁者に対して決裁を依頼する決裁申請書が申請書
作成者１０により起案され、作成される。このとき、こ
の決裁申請書が回付されるべき回付先が設定される。作
成された決裁申請書は、申請者１１から申請者１１の上
長１２に回付される。そして、決裁申請書の内容が上長
に承認されると、決裁申請において回付先として設定さ
れている管理部門１３Ａ、１３Ｂ、・・・にそれぞれ回
付される。

【００１１】決裁申請書は、回付先の管理部門１３Ａ、
１３Ｂ、・・・でそれぞれ検討され、全て承認される
と、事前確認部門１４Ａ、１４Ｂ、・・・にそれぞれ回
付される。同様にして、決裁申請書が回付先の事前確認
部門１４Ａ、１４Ｂ、・・・で全て承認されると、最終
的な決裁を行う決裁者１５に回付される。決裁者により
回付された決裁申請書の内容に対して決裁がなされる
と、その旨がここまでに回付されてきた各部門に対して
通知される。図１の例では、事前確認部門１４Ａ、１４
Ｂ、・・・、管理部門１３Ａ、１３Ｂ、・・・、上長１
２、申請者１１、ならびに、申請書作成者１０に対し
て、決裁がなされた旨が通知される。

【００１２】決裁者１５により決裁が承認されると、決
裁済みの決裁申請書が回付先として設定されている事後
連絡部門１６Ａ、１６Ｂ、・・・に回付される。また、
決裁の内容が金銭に関わるものである場合には、担当経
理１７にも決裁済みの決裁申請書が回付される。

【００１３】なお、管理部門１３Ａ、１３Ｂ、・・・、
事前確認部門１４Ａ、１４Ｂ、・・・、ならびに、事後
連絡部門１６Ａ、１６Ｂ、・・・は、同一の会社（組
織）内に限らず、関連会社の該当部門の場合もある。

【００１４】この実施の一形態では、上述の決裁申請書
の回付および決裁承認時の通知などが全てコンピュータ
ネットワーク上の電子メール機能を利用して行われる。
また、実施の一形態による決裁システムでは、関連会社
間で関連会社の枠を残しながら人事情報を共有するよう
にしている。人事情報を関連会社間で共有することによ
り、関連会社の承認を受けなければならない決裁の場合
でも、決裁の連絡先（回付先）を確定することが可能に
なる。さらに、この実施の一形態では、例えば決裁申請
書の回付ルートといった、関連会社毎の決裁ルールをテ
ーブル管理するようにしている。そのため、文化の異な
る関連会社との間でも、共同で決裁を行うことができ
る。

【００１５】図２は、このような決裁システムを実現す
るための、決裁データベースと決裁のフローとの相関を
概略的に示す。なお、以下の説明において、Ａ社は親会
社であり、この発明による決裁システムが置かれてい
る。Ｂ社およびＣ社は、Ａ社の関連会社であるとする。
関連会社は、Ｂ社およびＣ社の２社に限らず１社のみ、
あるいは、さらに多数でもよい。Ｂ社およびＣ社は、そ
れぞれ決裁権が独立され、人事や採算などが独立してい
る会社である。また、図２において、下側はＢ社のフロ
ーが示され、Ｃ社のフローは省略されている。

【００１６】決裁の基本的なフローそのものは、Ａ社、
Ｂ社およびＣ社で大きな差は無い。すなわち、例えばＡ
社において起案者２０により決裁が起案され、決裁申請
書が作成される。決裁申請書は、それぞれ１または複数
の管理者２１、２１、・・・、承認者２２、２２、・・
・、事前確認者２３、２３、・・・を介して決裁者２４
に渡され、決裁される。決裁申請書は、決裁者２４に直
接的に渡されず、決裁者２４の秘書２５を介することも
ある。決裁者２４により決裁されると、決裁書類２７が
作成されると共に、決裁結果が事後連絡者２６、２６、
・・・に渡される。決裁に金銭が関係するときは、担当
の経理２８にも渡される。このフローは、図２に示され
るように、Ｂ社およびＣ社においても、同様である。

【００１７】上述した決裁申請書の回付は、全てコンピ
ュータネットワーク上で電子メールを利用してなされ
る。例えばＡ社において、Ａ社の起案者２０により作成
された決裁申請書は、Ａ社の決裁データベース５０Ａに
格納される。起案者２０から管理者２１に対して決裁申
請がなされたことが電子メールで通知される。この電子
メールには、当該決算申請書の決裁データベース５０Ａ
に対するネットワーク上での格納場所（ＵＲＬ(Uniform
Resource Locator)）が記述されており、管理者２１
は、このＵＲＬに基づき決裁申請書を参照することがで
きる。

【００１８】以降の処理も同様にされ、承認者２２、事
前確認者２３および決裁者２４は、それぞれ電子メール
で決済申請書の回付を通知され、当該電子メールに記述
されているＵＲＬに基づき決裁データベース５０Ａにア
クセスし、決裁申請書を参照する。

【００１９】Ｂ社、Ｃ社においても、同様である。Ｂ社
の起案者２０’により作成された決裁申請書は、Ｂ社の
決裁データベース５０Ｂに格納される。管理者２１’、
承認者２２’、事前確認者２３’および決裁者２４’
は、それぞれ電子メールで決裁申請書の回付を通知さ
れ、当該電子メールに記述されているＵＲＬに基づき決
裁データベース５０Ｂにアクセスし、所定に決裁申請書
確認画面を表示させ、決裁申請書を参照する。

【００２０】ここで、この実施の一形態による決裁シス
テムを構成する決裁データベース５０Ａと決裁データベ
ース５０Ｂとは、共通するハードウェアの、それぞれ論
理的に別にされた領域に格納される。すなわち、決裁シ
ステムは、関連各社を含めて唯一、存在する。

【００２１】また、決裁システムは、Ａ社およびＡ社の
関連会社であるＢ社、Ｃ社、・・・で共通する、決裁回
付ルートテーブル５１を有する。決裁回付ルートテーブ
ル５１は、決裁の種類に応じた回付先が各会社（Ａ社、
Ｂ社、Ｃ社、・・・）毎に格納されている。起案者２
０、２０’は、決裁申請書の作成時にこの決裁回付ルー
トテーブル５１を参照して決裁申請書の回付先を設定す
る。決裁回付ルートテーブル５１は、制限付きで外部か
らのアクセスが可能である。

【００２２】決裁は、関連他社で作成された決裁申請書
について行われることがあるため、例えばＡ社の管理者
２１、承認者２２および事前確認者２３、ならびに、Ｂ
社の管理者２１’、承認者２２’および事前確認者２
３’は、それぞれ互いの会社の決裁データベース５０Ａ
および５０Ｂを参照することができる。一方、法律に基
づき、起案を行う場所（組織など）と決裁を行う場所
は、同一である必要がある。すなわち、決裁者は、他社
の決裁を行うことができない。そのため、Ａ社の決裁者
２４は、Ａ社の決裁データベース５０Ａにしかアクセス
できない。同様に、Ｂ社の決裁者２４’は、Ｂ社の決裁
データベース５０Ｂにしかアクセスできない。

【００２３】この実施の一形態の決裁システムでは、上
述したように、決裁申請書の回付が電子メールを利用し
て行われると共に、決裁申請書は、関連会社にも回付さ
れる。そのため、決裁システムにおいて、自社および関
連会社の人事・組織情報および電子メールのアドレス情
報を統合し、一元的に管理する必要がある。図３および
図４は、人事・組織情報と電子メールアドレスを統合
し、一元的に管理する様子を概略的に示す。

【００２４】図３を参照し、Ａ社、Ｂ社およびＣ社は、
社員情報のデータベースとして、社員全ての電子メール
アドレスがデータベース化された電子メールアドレスデ
ータベース６０Ａ、６０Ｂおよび６０Ｃをそれぞれ有す
る。同様に、Ａ社、Ｂ社およびＣ社は、人事および組織
情報のデータベースとして、人事・組織データベース６
１Ａ、６１Ｂおよび６１Ｃをそれぞれ有する。人事・組
織データベース６１Ａ、６１Ｂおよび６１Ｃを用いて、
認証も行われる。

【００２５】Ａ社、Ｂ社およびＣ社それぞれの電子メー
ルアドレスデータベース６０Ａ、６０Ｂおよび６０Ｃ、
ならびに、人事・組織データベース６１Ａ、６１Ｂおよ
び６１Ｃは、バッチ処理により自動的に、会社毎にまと
められて統合され、全社の組織マスタデータベース６２
に格納される。Ａ社に関連するＢ社、Ｃ社では、例えば
Ａ社の役員などが職務を兼任していることが有り得る。
この組織マスタデータベース６２は、このような兼任に
関する情報も格納される。

【００２６】組織マスタデータベース６２から人事情
報、組織情報および電子メールアドレスが抽出され、人
事・組織・電子メールアドレスデータベース６３に格納
される。この人事・組織・電子メールアドレスデータベ
ース６３に格納された情報は、Ａ社、Ｂ社およびＣ社で
共通して用いられる。

【００２７】図４は、上述したデータベースの統合処理
の一例をより具体的に示す。図４Ａに一例が示されるよ
うに、Ａ社、Ｂ社およびＣ社の人事・組織データベース
６１Ａ、６１Ｂおよび６１Ｃは、例えば社員番号、所
属、名前および役職などのフィールドを持ち、社員のそ
れぞれについて情報が記述される。また、この例では、
「山田一夫」氏は、Ａ社、Ｂ社およびＣ社で役職を兼任
していることが分かる。これらのデータと、図示されな
い電子メールアドレスデータベース６０Ａ、６０Ｂおよ
び６０Ｃに格納されている情報とがバッチ処理で自動的
に統合され、図４Ｂに一例が示されるようなデータとさ
れる。この図４Ｂに示されるデータが人事・組織・電子
メールアドレスデータベース６３に格納される。

【００２８】データベースの統合の方法としては、２通
りが考えられる。第１は、図５に一例が示されるよう
に、関連会社のデータベースから抽出したデータをＡ社
のデータベースの標準フォーマットに変換して、Ａ社の
データベースに格納する方法である。関連会社側のデー
タベース６０Ｂ、６０Ｃ、・・・、６１Ｂ、６１Ｃ、・
・・から所定に抽出されたデータがＡ社の標準的なフォ
ーマットに変換される。この変換処理は、例えば日毎に
バッチ処理で自動的になされる。標準フォーマットに変
換されたデータは、必須エラーチェックによりエラーが
無いかどうかがチェックされ、Ａ社に置かれたＢ社用の
決裁データベース５０Ｂ、Ｃ社用の決裁データベース５
０Ｃ、人事・組織・電子メールアドレスデータベース６
３にそれぞれ格納される。

【００２９】第２は、図６に一例が示されるように、関
連会社であるＢ社、Ｃ社、Ｄ社が親会社であるＡ社の決
裁データベース５０Ａ、人事・組織・電子メールアドレ
スデータベース６３をコピーして用いる方法である。こ
の場合、決裁システムそのものも、親会社から関連会社
にコピーされ用いられる。

【００３０】図７は、この実施の一形態による決裁シス
テムの一例のハードウェア的な構成を示す。例えばＬＡ
Ｎ(Local Area Network)からなるネットワーク１００
に、起案者用端末１０１、管理者用端末１０２、事前確
認者用端末１０３、決裁者用端末１０４および事後連絡
用端末１０５がそれぞれ接続される。これら端末１０１
〜１０５は、例えばパーソナルコンピュータである。

【００３１】また、Ａ社のネットワーク１００に決裁シ
ステムサーバ１０６が接続される。この決裁システムサ
ーバ１０６は、決裁システムの機能を提供するものであ
り、決裁システムを実行させる機能を有するソフトウェ
アが搭載されると共に、上述した人事・組織・電子メー
ルアドレスデータベース６３、決裁データベース５０お
よび決裁回付ルートテーブル５１を有する。決裁データ
ベース５０は、Ａ社の決裁データベース５０Ａの他に、
関連会社の決裁データベース、例えば決裁データベース
５０Ｂを含む。これら決裁データベース５０Ａおよび５
０Ｂは、単一のハードウェア上に、それぞれ分離されて
独立的に構成される。このように、この実施の一形態に
おいて、決裁システムサーバ１０６は、１台のハードウ
ェアで構成され、決裁システムの機能を複数台のハード
ウェアにより分散的に実行するようには構成されない。

【００３２】さらに、決裁システムサーバ１０６は、状
況に応じた電子メールのフォーマットがそれぞれ格納さ
れた、メールフォーマットデータベース５２を有する。
例えば上述の、決裁申請書の回付を通知する電子メール
は、このメールフォーマットデータベース５２が参照さ
れて作成される。

【００３３】さらにまた、図示しないが、ネットワーク
１００には、電子メールの通信を制御するメールサーバ
が接続される。

【００３４】端末１０１〜１０５は、特に区別されてい
る必要はなく、例えばユーザが使用する際に、ユーザ名
とパスワードを入力するようにして、入力されたユーザ
名およびパスワードの組み合わせに基づき権限を設定す
るようにしてもよい。

【００３５】なお、例えば起案者端末１０１は、ＧＵＩ
(Graphical User Interface)が適用され、マウスなどの
ポインティングデバイスを用いてユーザによる直感的な
操作が可能とされている。例えば、画面に所定に配置さ
れ表示されたボタンなどを、ポインティングデバイスか
ら出力される座標情報に基づき指示し、ポインティング
デバイスに対して所定の操作を行うことで、表示された
ボタンに割り当てられた機能を実行させることができ
る。以下、このポインティングデバイスを用いたボタン
表示に対する一連の処理を、「ボタンを操作する」、
「ボタンを押す」などと表現する。勿論、ポインティン
グデバイスだけでなく、例えばキーボードなどの他の入
力手段を用いて所定の機能を実行させるようにもでき
る。同様に、決裁システムサーバ１０６やメールサーバ
は、一般的なサーバ装置を用いることができる。これら
各端末および各サーバ装置についての詳細な説明は省略
する。

【００３６】Ｂ社においても同様に、ネットワーク１１
０に対して、起案者用端末１１１、管理者用端末１１
２、事前確認者用端末１１３、決裁者用端末１１４およ
び事後連絡用端末１１５がそれぞれ接続される。図示し
ないが、メールサーバもネットワーク１１０に接続され
る。Ｃ社も同様である。ネットワーク１２０に対して起
案者用端末１２１、管理者用端末１２２、事前確認者用
端末１２３、決裁者用端末１２４および事後連絡用端末
１２５がそれぞれ接続され、さらに、図示されないメー
ルサーバが接続される。

【００３７】Ａ社のネットワーク１００と、Ｂ社のネッ
トワーク１１０と、Ｃ社のネットワーク１２０とは、さ
らにネットワーク１３０、１３１で接続される。この、
関連会社間でのネットワーク接続は、例えばインターネ
ットや所定のプロトコルによるＷＡＮ(Wide Area Netwo
rk)を用いることができる。Ｂ社およびＣ社では、これ
らネットワーク１３０、１３１を介して、Ａ社に設けら
れた決裁システムサーバ１０６により提供される決裁シ
ステムを利用することができる。

【００３８】Ａ社、Ｂ社、・・・の各端末装置には、決
裁システムサーバ１０６から提供される決裁システムの
端末として機能するソフトウェアが搭載される。これ
は、決裁システムサーバ１０６上で公開されているファ
イルを、ネットワークを介して閲覧するようにされた、
所謂ブラウザソフトウェアを用いることができる。この
ブラウザソフトウェアは、ネットワークを介して読み込
まれたファイルに基づき所定の表示を行う機能を有する
と共に、ファイルに指定された手段で決裁システムサー
バ１０６にデータを送信することができる。各端末装置
に搭載されるソフトウェアは、これに限らず、端末側か
ら決裁システムサーバ１０６に対して積極的にデータを
要求するようなものでもよい。

【００３９】さらに、Ａ社、Ｂ社、・・・の各端末装置
には、決裁システムサーバ１０６からメールサーバを介
して送信される電子メールを受信するためのソフトウェ
ア（メーラ）が搭載される。メーラは、上述した決裁シ
ステムの端末として機能するソフトウェアに内蔵されて
いてもよい。決裁システムサーバ１０６から送信された
電子メールは、メールサーバを介して、電子メールに宛
先（電子メールアドレス）で指定されたユーザに受信さ
れる。受信された電子メールは、メーラにより表示され
る。

【００４０】ここで、電子メールの文中にＵＲＬが記述
されている場合には、その表示箇所を、例えばマウスな
どのポインティングデバイスを用いて所定に指定するこ
とで、そのＵＲＬに記述されているファイルに自動的に
アクセすることができるようにされている。例えば、電
子メールの文中に上述した決裁システムのファイルの場
所がＵＲＬで記述してあれば、ブラウザソフトウェアが
自動的に起動され、当該ファイルがネットワークを介し
て読み込まれブラウザソフトウェア上に表示される。

【００４１】なお、ＵＲＬにより他のファイルにアクセ
スできるようにすることを「リンクを貼る」と称し、こ
のときのＵＲＬそのものを「リンク」と称する。

【００４２】次に、この実施の一形態の決裁システムに
よる決裁処理について概略的に説明する。図８〜図１０
は、この実施の一形態の決裁システムによる一例の決裁
処理を説明するためのフローチャートである。図８〜図
１０のフローチャートにおいて、符号Ａ、Ｂ、Ｃおよび
Ｄは、それぞれ対応する符号へ処理が移行することを示
す。

【００４３】なお、以下では、Ａ社の齋藤花子氏により
決裁が起案され、Ａ社、ならびに、Ａ社の関連会社であ
るＢ社およびＣ社で管理確認および事後確認を行い、決
裁は起案がなされたＡ社で行われ、決裁後の事後確認を
Ｃ社で行う例について説明する。

【００４４】図８において、最初のステップＳ１０で決
裁が起案される。例えば、Ａ社の社員である齋藤花子氏
により決裁が起案される場合について考える。先ず、齋
藤花子氏は、決裁申請書を作成するために、起案者端末
１０１から決裁システムにログインする。所定のログイ
ン画面に対してＩＤ（名前）とパスワードが入力され、
これらＩＤおよびパスワードに基づき組織マスタデータ
ベース６２が参照されて決裁システムにおいて齋藤花子
氏が認証され、ログインした者に対する決裁システム上
での権限が設定される。

【００４５】起案に基づきＡ社の起案者端末１０１から
決裁申請書が作成される。図１１は、起案者端末１０１
において決裁申請書を作成する決裁申請書作成画面２０
０の一例を示す。決裁申請書作成画面２００の所定の項
目にデータを入力することで、決裁申請書が作成され、
作成された決裁申請書が決裁データベース５０Ａに登録
される。

【００４６】起案時には、件名、マル秘指定、決裁種
類、決裁の内容などが決裁申請書作成画面２００から入
力され、決裁申請書が作成される。決裁に出勤が関係す
るような場合には、経理についても入力される。また、
作成された決裁申請書の回付ルートが別途、回付ルート
設定画面から入力される。

【００４７】件名が入力部２０１に入力される。入力部
２０２は、この決裁申請書の機密度が入力される。機密
度は、右端に設けられたボタンを押すことで表示される
機密度の一覧から選択されて入力され、マル秘指定など
もここで指定される。入力部２０２において、「回付ル
ート設定者のみに公開」を選択すると、マル秘設定など
の機密設定をしたとされる。

【００４８】入力部２０３は、この決裁申請書の決裁種
別が入力される。決裁種別は、例えば、顧客へ提出する
見積書の決裁である見積決裁、開発、保守など、外注委
託の決裁である委託決裁、新たな取引先に関する決裁で
ある取引決済、資金の調達や運用に関する決裁である財
務決裁がある。入力部２０３において、「一覧から選
択」ボタン２０３Ａを押すことで、選択可能な決裁種別
の一覧がリスト表示される。このリストから所望の決裁
種別を選択し、決裁種別が入力される。

【００４９】入力部２０４は、決裁の区分が入力され
る。ここでも、右端に設けられたボタンを押すことで、
選択可能な決裁区分の一覧がリスト表示され、このリス
トから決裁区分が選択される。入力部２０５には、この
決裁申請書で申請される決裁の内容や概要といった、決
裁のより具体的な内容が入力される。別途、添付ファイ
ルが存在するときには、「添付ファイルアップロード」
ボタン２０６を押すことで、ファイル添付画面が表示さ
れ、所望のファイルをこの決裁申請書に添付することが
できる。また、この決裁申請書で申請される決裁におい
て、電子データ化できない、実体としての添付物を添付
する必要がある場合は、入力部２０７のチェックボック
スにチェックを入れることで、実体添付物があることが
決裁申請書に反映される。

【００５０】なお、決裁申請書は、過去に既に作成され
た決裁申請書を流用して作成することができる。例え
ば、画面２００上に設けられたボタン２０８を押すこと
で、過去に作成された決裁申請書の検索画面が表示され
る。この検索画面に対して所定の検索条件を入力する
と、決裁データベース５０Ａおよび５０Ｂが検索され、
検索条件に適った決裁申請書のデータが決裁申請書作成
画面２００の対応箇所にそれぞれ自動的に入力され、各
入力部に表示される。起案者は、決裁申請書作成画面２
００の各入力部のデータを所定に変更して、新規の決裁
申請書を作成することができる。

【００５１】決裁申請書作成画面２００の上部に設けら
れた「ルート設定」ボタン２１０を押すことで、図１２
に一例が示される、回付ルート設定画面２２０が表示さ
れる。この回付ルート設定画面２２０により、作成され
た決裁申請書の回付先が設定される。回付先としては、
一例として申請者、上長、管理部門、事前確認者、決裁
者、事後連絡者などが設定され、必要であれば、担当経
理も設定される。

【００５２】これらの回付先のうち、管理部門は、設定
された回付先が決裁のルールに従っているかどうかの確
認や、決裁申請書の記載項目の誤記や抜けのチェックな
どを行う。事前確認者は、この決裁申請書による決裁と
関係する部門での、決裁に対する事前確認を行う。事後
確認（事後連絡）者は、決裁後に決裁がされたことを確
認する。また、担当経理は、決裁に出金が関係する場合
に限定的に回付先に設定される。上述したように、決裁
は、決裁が起案された会社でなされる必要があるため、
決裁者は、起案者が所属する会社に所属している者であ
る。

【００５３】図１２において、入力部２２１および２２
２に、この決裁申請書の作成者の名前および電子メール
アドレスが入力される。これは、決裁システムに対する
ログイン時に入力されたＩＤおよびパスワードにより、
自動的に入力可能である。入力部２２３および２２４に
は、この決裁申請書による決裁の申請者の名前および電
子メールアドレスが入力される。決裁申請書の作成者と
申請者とが同一人物の場合には、「作成者と同じ」と表
記されたボタンを押すことで、入力部２２１および２２
２に入力された内容が入力部２２３および２２４にその
まま反映される。

【００５４】回付ルート設定画面２２０において、予
め、決裁申請書の回付先として上長、管理部門、事前確
認部門、決裁者、担当経理および事後連絡部門の入力部
がそれぞれ設けられる。管理部門を例にとると、表示部
２２５には、この決裁申請書の回付先の候補となる部門
がリストアップされて表示される。表示部２２５にリス
ト表示された回付先候補の中から所望の回付先を選択
し、表示部２２５の左端側に設けられた左向きの矢印ボ
タンを押すことで、選択された回付先が表示部２２６に
表示され、実際の回付先として設定される。回付先は、
決裁者を除き、複数、設定することができる。

【００５５】表示部２２５のリスト表示は、例えば、起
案者の所属や、決裁申請書作成画面２００で入力された
決裁種別、決裁区分などに基づき、回付先ルートテーブ
ル５１を参照して自動的に表示させるようにできる。回
付先ルートテーブル５１には、上述したように、関連会
社であるＢ社、Ｃ社、・・・の回付先情報も格納されて
いる。そのため、回付ルート設定画面２２０では、関連
会社Ｂ社、Ｃ社、・・・の回付先を含めて設定すること
ができる。

【００５６】表示部２２５に表示される回付先候補のリ
ストに、新規の回付先を追加することができる。図１３
を用いて、新規に回付先を追加する手順について概略的
に説明する。新規に回付先を追加する場合、先ず、回付
ルート設定画面２２０の、回付先を追加したい部門（こ
こでは管理部門とする）の表示領域に設けられている
「新規宛先追加」ボタン２２７を押す。すると、図示は
省略するが、回付先を追加したい部門が所属する会社
（組織）を選択する選択画面が表示される。

【００５７】この選択画面から所望の会社を選択する
と、図１３Ａに一例が示される組織／社員設定画面２３
０が表示される。組織／社員設定画面２３０は、例えば
人事・組織・電子メールアドレスデータベース６３が参
照されて表示される。この組織／社員設定画面２３０
は、例えば社内および関連会社のネットワーク上での電
話帳の役割を果たすものと兼用できる。

【００５８】この組織／社員設定画面２３０において、
左側には、選択された会社の部署が一覧表示されるの
で、回付先として設定したい者が所属する部署を選択す
る。図１３Ａの例では、反転表示により選択された部署
が示されている。部署が選択されると、組織／社員設定
画面２３０の右側に選択された部署に所属する社員が一
覧表示される。この一覧表示から、該当者を所定に選択
する。図１３Ａでは、丸印（○）の部分にチェックが入
ることで、選択された者が示されている。これにより、
図１３Ｂに示されるように、選択結果が表示部２２５に
反映され、回付先候補が新規に追加される。ここで、追
加された回付先候補を選択して左側向きの矢印ボタンを
押すことで、図１３Ｃに示されるように、その回付先候
補が回付先として設定される。

【００５９】説明は図８のフローチャートに戻り、この
ようにしてステップＳ１０で決裁申請書の作成および作
成された決裁申請書の回付先が設定されると、処理はス
テップＳ１１に移行し、申請された決裁に対してユニー
クな決裁ＩＤが発行される。決裁ＩＤは、既に決裁がな
された決裁申請書に設定された決裁ＩＤとも重複しない
ように設定される。例えば、決裁ＩＤは、決裁申請書が
作成あるいは登録された日と、その日までに発生した決
裁の数、決裁の種類などの情報に基づき生成される。

【００６０】設定された決裁ＩＤは、決裁申請書作成画
面２００の表示部２０９に申請番号として表示される。
決裁ＩＤが発行されると、処理はステップＳ１３に移行
し、作成された決裁申請書の内容が決裁内容として、起
案者である齋藤花子氏の所属するＡ社の決裁データベー
ス５０Ａに登録される。

【００６１】決裁申請書が決裁データベース５０Ａに登
録されると、次のステップＳ１３で、指定された回付先
として設定された者全てに対して、決裁が発生したこと
を通知する所定のフォームに従った電子メールが送信さ
れる。上述したように、決裁申請書の回付先は、人事・
組織・電子メールアドレスデータベース６３が参照され
て設定されている。そのため、電子メールの送信先のア
ドレスは、人事・組織・電子メールアドレスデータベー
ス６３から検索されて指定され、起案者は、それぞれの
回付先の電子メールアドレスを特に指定する必要がな
い。

【００６２】次のステップＳ１４では、回付先の電子メ
ールアドレスがチェックされ、電子メールアドレスの誤
記の有無や、存在しない相手に電子メールを送信しよう
としていないかどうかが判断される。若し、電子メール
アドレスの送信先アドレスにこのような不備があるとさ
れれば、送信された電子メールが回付されるべき相手に
正しく送信できず、処理はステップＳ１５に移行する。
この実施の一形態では、ステップＳ１３で回付先に送信
される電子メールにおいて、起案者の電子メールアドレ
スが送付元とされ、ステップＳ１５では、送信先のアド
レスに不備がある電子メールが起案者に返される。起案
者は、この電子メールを受け取った後、当該決裁申請書
の回付先ルートの内容を修正して再び決裁申請を行うこ
とができる。

【００６３】従来の同様なシステムでは、システムから
発行される電子メールは、発行元がシステム自身が持っ
ているアドレスになっていた。そのため、送信先アドレ
スに不備があり送信できなかった場合でも、その旨が通
知されるリプライ先がシステムになってしまい、その電
子メールを発行した本人である起案者は、送信先アドレ
スに不備があり電子メールが想定された送付先に送信で
きなかったことを知り得なかった。この発明では、上述
したように、発行される電子メールは、送信先アドレス
に不備があるような場合のリプライ先として起案者が指
定され、システムに電子メールが戻るようにしながら、
起案者にも常に戻るようにされている。そのため、起案
者は、決裁の通知の上で問題を直接的に受けられるよう
になっているというメリットがある。

【００６４】なお、上述では決裁の起案者すなわち決裁
の申請者が決裁申請書を作成し、申請者が申請書作成者
を兼ねているが、申請者と申請書作成者がそれぞれ存在
する場合も有り得る。この場合には、申請書作成者によ
り決裁申請書が作成されたら、先ず、申請者により、作
成された決裁申請書が承認される。承認されない場合に
は、その旨が電子メールで申請書作成者に自動的に通知
され、当該決裁申請書は、申請書作成者に差し戻され
る。

【００６５】以上のステップＳ１０乃至Ｓ１４（または
Ｓ１５）までが、起案者により起案者端末１０１からな
される処理である。次のステップＳ１６からは、管理者
により管理者端末１０２から行われる処理になる。な
お、以下では管理担当者による承認について述べるが、
この管理担当者による承認の前段階である上長による承
認処理も、管理担当者による承認処理と同様にして行わ
れる。ここでは、繁雑さを避けるため、上長による承認
処理の説明を省略する。

【００６６】ステップＳ１４で、決裁発生を全回付先に
通知する電子メールの送付先アドレスが正しいと判断さ
れれば、Ａ社においては、処理はステップＳ１６に移行
する。この例では、管理確認および事前確認がＢ社およ
びＣ社でも行われるため、回付先としてこれらＢ社およ
びＣ社も指定されている。したがって、決裁発生の通知
が回付先として設定された者が所属するＢ社およびＣ社
にも送信され、Ａ社の処理と並行して、図１０に一例が
示されるＢ社の処理が行われる。この図１０のＢ社の処
理については、後述する。また、Ｃ社の処理はＢ社と同
様なので、説明を省略する。

【００６７】ステップＳ１６では、管理担当者により、
管理者端末１０２から決裁システムにログインされる。
ログインの際には、上述と同様に、所定のＩＤとパスワ
ードが入力され、ログインした管理担当者の認証がなさ
れ、決裁システム上での権限が設定される。なお、管理
担当者が複数の部署を兼務している場合がある。管理担
当者が決裁システムにログインすると、ログイン時の認
証情報に基づき人事・組織・電子メールアドレスデータ
ベース６３が参照され、当該管理担当者が複数部署を兼
務しているかどうかが調べられる。兼務していると判断
されれば、図１４に一例が示されるような画面が表示さ
れ、兼務している部署のうち、どの部署を処理対象とし
て決裁システムにアクセスするかが選択される。

【００６８】管理担当者により決裁システムがアクセス
されると、先ず、当該管理担当者が関係する未確認の決
裁があるかどうかが確認される。図１５は、未承認決裁
を確認するための未承認決裁確認画面２４０の一例を示
す。例えば、ログイン時に入力されたＩＤとパスワード
とから人事・組織・電子メールアドレスデータベース６
３が参照されて得られた管理担当者の情報に基づき決裁
データベース５０Ａおよび５０Ｂが検索され、当該管理
担当者が回付先として指定されており、且つ、当該管理
担当者に承認などの確認処理が行われていない決裁申請
書が抽出される。抽出された決裁申請書の情報が表示部
２４１に一覧表示される。

【００６９】当該管理担当者は、表示部２４１に一覧表
示された決裁申請書から承認を行おうとするものを選択
する。この場合は、ステップＳ１４で電子メールにより
通知された決裁申請書が承認すべきものとして選択され
る。選択された決裁申請書は、決裁データベース５０Ａ
または５０Ｂ（この場合は決裁データベース５０Ａ）か
ら読み出され、決裁申請書確認画面として所定に表示さ
れる。決裁申請書確認画面は、決裁データベース５０Ａ
または５０Ｂから検索されて得られた当該決裁申請書の
情報と、この決裁申請書確認画面にアクセスした者の情
報に基づき、ＣＧＩ(Common Gateway Interface)などの
スクリプトにより、管理担当者のこの決裁申請書に対す
る立場および処理に応じて自動生成される。決裁申請書
確認画面の詳細については、後述する。ステップＳ１７
で、当該管理担当者により、この決裁申請書確認画面の
表示に基づき決裁申請書が確認される。

【００７０】このとき、回付先として事前確認者などを
追加することができる。回付先が追加されたことは、起
案者からも、決裁システムを介して決裁状況で知ること
ができる。

【００７１】次のステップＳ１８で、当該決裁申請書に
ついて回付先などの確認が行われ、問題があるかどうか
が判断される。若し、問題があると判断された場合に
は、処理はステップＳ１９に移行し、その旨が決裁申請
書にコメントとして付記され、起案者に対して所定のフ
ォームの電子メールで通知される。起案者は、この電子
メールを受け取った後、決裁申請書の内容を修正して再
び決裁申請を行うことができる。

【００７２】一方、ステップＳ１８で、管理担当者によ
り問題がないと判断されれば、処理はステップＳ２０に
移行する。ステップＳ２０では、管理担当者により、決
裁申請書に基づき決裁内容に関して判断がなされる。若
し、決裁内容に関して問題があると判断されれば、当該
決裁申請は却下されることになる。

【００７３】当該決裁申請が却下されると、処理はステ
ップＳ５０に移行し、当該決裁申請書による起案が取り
下げられる。そして、ステップＳ５１で、その旨が決裁
申請書に回付先として設定されている関係各位のうち、
ここまでの回付ルートにあった者、起案者、ならびに、
同じ管理担当者でも、この決裁申請書について既に確認
してしまった者に対して、それぞれ所定のフォームの電
子メールで通知される。そして、次のステップＳ５２
で、当該決裁申請書が起案者に対して差し戻される。

【００７４】一方、上述したステップＳ２０で決裁内容
に関して内容に問題が無いと判断されれば、処理はステ
ップＳ２１に移行し、決裁申請書確認画面に所定に設け
られた確認ボタンが押され、決裁依頼が発生されて、処
理はステップＳ２２に移行する。この、当該決裁申請書
に対してなされた確認は、決裁データベース５０Ａに格
納された当該決裁申請書の情報に反映される。

【００７５】ステップＳ２２では、上述したステップＳ
１４と同様にして、当該決裁申請書に設定された次の回
付先の電子メールアドレスがチェックされ、問題がない
かどうかが確認される。若し、回付先の電子メールアド
レスに何らかの不備があれば、処理はステップＳ２３に
移行し、不備がある電子メールが起案者に返される。

【００７６】一方、回付先の電子メールアドレスに不備
がないとされれば、処理はステップＳ２４に移行され、
当該決裁申請書において設定された回付先およびステッ
プＳ１７で追加された回付先に基づき、事前確認者に対
して決裁依頼が発生した旨が所定のフォームの電子メー
ルでそれぞれ通知される。複数の事前確認者への通知が
並列的に行われるため、印刷された書類による決裁のよ
うに複数の事前確認者への通知が直列的に行われる場合
に比べ、迅速に処理することが可能である。

【００７７】以上のステップＳ１６乃至Ｓ２４までが、
管理担当者により管理者端末１０２からなされる処理で
ある。次のステップＳ２５（図９）からは、事前確認者
により事前確認者端末１０３から行われる処理になる。

【００７８】ステップＳ２５では、回付ルート先とされ
た事前確認者に決裁依頼が通知された電子メールが受け
取られる。すると、図９のフローチャートでは省略され
ているが、上述したステップＳ１６と同様に、事前確認
者により事前確認者端末１０３から決裁システムにログ
インされる。事前確認者により所定のＩＤとパスワード
が入力され、ログインした事前確認者の認証がなされ、
決裁システム上での権限が設定される。事前確認者が複
数の部署などを兼務している場合には、上述した図１４
に示されるような画面から処理対象の部署が選択され、
決裁システムへのログインがなされる。

【００７９】事前確認者は、決裁システムにログインす
ると、未承認決裁を確認するための未承認決裁確認画面
２４０を表示させ、表示部２４１に一覧表示された決裁
申請書から、ステップＳ２５において電子メールで通知
を受け取った決裁申請書を、確認すべきものであるとし
て選択する。すると、選択された決裁申請書に基づく決
裁申請書確認画面が表示される。決裁申請書確認画面
は、決裁データベース５０Ａから検索されて得られた当
該決裁申請書の情報と、この決裁申請書確認画面にアク
セスした者の情報に基づき、事前確認者のこの決裁申請
書に対する立場および処理に応じたＣＧＩなどのスクリ
プトにより自動生成される。決裁申請書確認画面の詳細
については、後述する。

【００８０】なお、ここでは、上述の管理担当者の場合
とは異なり、回付先すなわち決裁者の追加を行うことが
できない。これは、事前確認者よりも上位の者がいない
ためである。

【００８１】次のステップＳ２６で、事前確認者によ
り、決裁申請書に示される決裁内容から、問題の有無が
判断される。若し、問題がないと判断されれば、処理は
ステップＳ２９に移行する。一方、決裁申請書に示され
る決裁内容に問題があると判断されれば、処理はステッ
プＳ２７に移行され、その旨が起案者に所定のフォーム
の電子メールで通知される。

【００８２】なお、決裁申請書の内容に問題がある場合
には、上述の管理担当者や上長の段階では当該決裁申請
書が起案者に差し戻しとなったが、事前確認者の段階で
は差し戻しとはならない。事前確認者の段階では、ステ
ップＳ２８により、当該決裁申請書に対して異議有りを
示すフラグが付され、この異議有りフラグが決裁者に持
ち越される。すなわち、この異議有りフラグにより、決
裁者は、事前確認者の確認の段階で問題があったことが
分かり、この異議も含めて最終的な判断を下すことがで
きる。異議有りフラグが当該決裁申請書に付されると、
処理はステップＳ２９に移行される。

【００８３】ステップＳ２９で当該決裁申請書による決
裁依頼の内容が事前確認者により確認されたら、例えば
決裁申請確認画面に所定に設けられた確認ボタンが押さ
れる。当該決裁申請書が事前確認者に確認されたこと
は、決裁データベース５０Ａの当該決裁申請書情報に反
映される。そして、次のステップＳ３０で、決裁依頼が
発生していることが決裁者に所定のフォームの電子メー
ルで通知される。それと共に、決裁者の秘書にも並列的
に、決裁依頼が発生していることが所定のフォームの電
子メールで通知される（ステップＳ３１）。

【００８４】上述したステップＳ１４によりＢ社に送信
された決裁申請の通知に基づき、Ｂ社でも、略同様の手
順を経て事前確認者による決裁申請書の確認までの処理
が行われる。Ｂ社の処理について、図１０のフローチャ
ートを用いて説明する。なお、図１０において、上述し
た図８および図９と対応する処理には同一の符号にダッ
シュ（’）を付して示し、図８および図９に示される処
理との差異部分についてのみ説明する。

【００８５】Ｂ社における処理は、起案がなされたＡ社
における処理と略同一であり、ステップＳ１６’で回付
先ルートに設定されたＢ社の管理担当者により決裁シス
テムがアクセスされ、ステップＳ１７’で決裁申請書が
確認される。ここで、上述したＡ社と異なる処理とし
て、次のステップＳＡで、通知された決裁申請書に設定
された回付ルートが社内回付先として、自社の担当者、
内容などがＢ社の社内ルールに適合しているかどうかが
判断される。この場合は、事前確認者の回付先が判断さ
れることになる。若し、適合していないと判断されれ
ば、ステップＳ１８’で当該決裁申請書に問題有りと判
断され、ステップＳ１９’で起案者であるＡ社の齋藤花
子氏にその旨通知される。

【００８６】以降、ステップＳ２０’で決裁内容に問題
が無いかどうか判断され、問題が無ければステップＳ２
１’で決裁依頼が発生される。若し、問題があれば、処
理はステップＳ５０’に移行して当該決裁申請書による
起案が取り下げられ、ステップＳ５１’で関係各位に所
定のフォームの電子メールでその旨通知がなされると共
に、ステップＳ５２’で、当該決裁申請書が起案者に差
し戻される。そして、ステップＳ２２’で回付ルートに
問題が無いかどうか判断され、問題があればその旨起案
者に所定のフォームの電子メールで通知され、問題が無
ければ処理はステップＳ２４’に移行する。

【００８７】ステップＳ２４’からＢ社の事前確認者の
処理に移行する。ステップＳ２４’では、事前確認者に
より決裁システムにアクセスされ決裁依頼が受け取られ
る（ステップＳ２５’）。ステップＳ２６’で決裁申請
書の内容に問題が無いかどうか判断され、問題が無けれ
ばステップＳ２９’で決裁依頼内容が確認される。若
し、問題があれば、ステップＳ２７’でその旨が所定の
フォームの電子メールで起案者に通知され、ステップＳ
２８’で、当該決裁申請書に対して異議有りを示すフラ
グが立てられ、必要であればコメントが付加され、処理
はステップＳ２９’に移行される。そして、Ｂ社からＡ
社の決裁者および決裁者の秘書に対して、決裁依頼の通
知がなされる（ステップＳ３０’およびＳ３１’）。

【００８８】上述もしたが、決裁は、起案がなされた会
社と同一の会社で行われる必要がある。この例では、決
裁の起案者がＡ社の齋藤花子氏であるところから、決裁
も、Ａ社の決裁者例えば社長によってなされる。決裁依
頼の通知先の秘書としては、Ａ社の決裁者（社長）の秘
書に通知がなされ、Ａ社の決裁者がＢ社やＣ社の決裁者
を兼ねているような場合でも、Ｂ社における当該決裁者
の秘書やＣ社における当該決裁者の秘書には決裁依頼は
通知されない。

【００８９】ここで、決裁者によっては、長期出張や兼
務などの関係から、一時期に大量の決裁を行わないとい
けない場合も有り得る。そこで、この実施の一形態で
は、上述した事前確認者の段階で、当該決裁申請書に対
して確認を行うように回付ルートに設定された事前確認
者の全てが、当該決裁申請書の内容に問題が無いと判断
した場合に、自動的に、当該決裁申請書に基づく決裁を
行うように設定することが可能である。このような設定
は、起案者による決裁申請書作成の段階で行ってもよい
し、管理担当者や事前確認者による承認の段階で行って
もよい。また、決裁者自らにより、例えば所定の条件を
満たす決裁申請に対して自動的に設定されるようにして
もよい。

【００９０】決裁者および決裁者の秘書に対する通知が
全て集まったら、ステップＳ３２で、当該決裁申請書が
自動決済を行うように設定されているかどうかが判断さ
れる。若し、自動決済するように設定されていないと判
断されれば、処理はステップＳ３３に移行し、決裁者に
よる決裁を行うようにされる。

【００９１】一方、自動決済するように設定されている
と判断されれば、処理はステップＳ３４に移行する。ス
テップＳ３４では、当該決裁申請書が、回付ルートに設
定されている全ての事前確認者により問題無いとして承
認されているかどうか判断される。この判断は、例えば
決裁データベース５０Ａに格納された当該決裁申請書情
報が参照されることで行われる。若し、問題無いとして
承認されていれば、処理はステップＳ３５に移行し、自
動決済を行うように決定される。一方、当該決裁申請書
の回付ルートに設定された事前確認者のうち少なくとも
一人が当該決裁申請書を承認していなければ、処理はス
テップＳ３３に移行し、決裁者による決裁を行うように
決定される。

【００９２】ステップＳ３３あるいはステップＳ３５か
ら処理はステップＳ３６に移行される。ステップＳ３６
では、決裁者により決裁申請書確認画面が表示され、こ
の画面表示に基づき当該決裁申請書の内容に対して判断
がなされ、決裁が行われる。すなわち、上述のステップ
Ｓ３０で受け取った電子メールに記述されたＵＲＬを所
定に指定することで、決裁データベース５０Ａが所定に
検索され当該決裁申請書の情報が得られると共に、この
決裁申請書確認画面にアクセスした者の情報が得られ、
これらの情報に基づき、ＣＧＩなどのスクリプトにより
決裁者および処理に応じた決裁申請書確認画面が自動生
成される。決裁申請書確認画面の詳細については、後述
する。

【００９３】この実施の一形態による決裁システムで
は、決裁の結果として、「承認（決裁）」および「却
下」に加えて、「説明を要求」を選択できる。決裁者に
よる決裁の場合には、上述した事前確認者による異議有
りフラグが加味されて、検討がなされる。なお、上述の
ステップＳ３５で自動決済を行うように決定されている
場合には、このステップＳ３６では、「決裁」が選択さ
れる。

【００９４】ステップＳ３６の決裁判断において、当該
決裁申請書の内容に問題が無く、「決裁」が選択された
場合には、処理はステップＳ３７に移行し、決裁が完了
される。決裁が完了されると、ステップＳ３８で、決裁
が完了したことが所定のフォームの電子メールで通知さ
れる。通知先は、起案者および回付ルートに設定された
途中回付者とされる。それと共に、この例ではＣ社が事
後確認を行うようになっているため、Ｃ社の事後確認部
門が決裁完了の通知先とされる。Ｃ社の事後確認部門
は、起案時に指定された者および後から追加された者か
ら、途中で降りた者を差し引いたメンバとなる。

【００９５】また、決裁の内容に金銭が関連する場合、
すなわち、起案時に決裁種別として「見積もり決裁」あ
るいは「会計決裁」が指定されるか、または、決裁書類
上において金額に関する情報が盛り込まれて決裁データ
ベース５０Ａに登録された決裁は、所定の経理部門にも
決裁完了通知が自動的に送付される。

【００９６】さらに、ステップＳ３８の決裁通知の処理
と並行して、ステップＳ３９で、決裁書類が作成され
る。決裁書類は、例えばＰＤＦ(Portable Document For
mat)ファイルとして作成され、決裁書類ファイルとして
決裁データベース５０Ａに保存される。ＰＤＦは、Adob
e Systems Incorporatedにより開発されたドキュメント
ファイルのフォーマットであり、文字フォントの情報、
大きさや画像などのレイアウトを保持したままで表示す
ることができる。

【００９７】決裁完了の通知処理に関して、図１６およ
び図１７を用いてより具体的に説明する。決裁完了を通
知する電子メールは、例えば図１６に一例が示されるよ
うなフォームで送信される。後述するが、このフォーム
は、メールフォーマットデータベース５２に格納された
フォーマット情報に基づき、自動的に生成され送信され
る。電子メールが表示されるメーラの機能により、文面
中に記載されたＵＲＬ２５０を所定に指定することで、
該当する決裁申請書にアクセスすることができる。

【００９８】図１７は、上述のＵＲＬ２５０を指定して
アクセスされた決裁申請書の、各端末への一例の表示を
示す。決裁申請書は、この例では上部に申請番号および
決裁番号が記されこの決裁申請書が識別可能とされ、中
段に決裁者、上長、申請者、管理部門および事前確認部
門などの、この決裁申請書の回付先の情報が記されると
共に、承認の有無が記される。また、図示は省略する
が、決裁申請書の内容は、決裁申請書の下段に記され
る。この決裁申請書は、上述したＰＤＦで作成されたも
ので、決裁完了の通知先各々において、決裁書類ファイ
ルとして保存することができると共に、印刷して紙によ
る決裁申請書として保存することができる。

【００９９】上述したように、決裁書類ファイルは、ス
テップＳ３７の処理により決裁が完了した時点で生成さ
れる。この実施の一形態では、決裁完了以前の処理にお
ける決裁申請書の表示などは、全て、例えばＣＧＩを利
用して各データベースからデータを抽出し、抽出された
データを整形して用いるようにしている。こうすること
で、ネットワークへの負荷の低減、処理時間の短縮を実
現することができる。また、その都度データを抽出する
ため、ログインした者の決裁システム上での権限に応じ
た処理の実行を行うことが可能になる。

【０１００】一方、上述のステップＳ３６で、「説明を
要求」が選択された場合には、処理はステップＳ４１に
移行する。ステップＳ４１では、説明を要求する旨が記
述された所定のフォーマットの電子メールが送信され
る。図１８は、この電子メールの一例のフォームを示
す。後述するが、このフォームは、メールフォーマット
データベース５２に格納されたフォーマット情報に基づ
き、自動的に生成され送信される。電子メールが表示さ
れるメーラの機能により、文面中に記載されたＵＲＬ２
５１を所定に指定することで、該当する決裁申請書にア
クセスすることができる。この電子メールの宛先は、当
該決裁申請書の起案者とされ、ＣＣ(CarbonCopy)とし
て、当該決裁申請書の回付ルートに設定された各回付先
が設定される。なお、ＣＣは、送付先が公開された一斉
同報メールである。

【０１０１】この「説明を要求」が選択された場合に
は、このようにその旨示す通知が送信されると共に、決
裁そのものは、保留とされる。例えば、ステップＳ４２
に示されるように、ステップＳ４１において送信された
通知に対する返答が待たれ、返答があった場合には、処
理がステップＳ３６に戻され決裁判断を行うようにでき
る。

【０１０２】また、上述のステップＳ３６で、「却下」
が選択された場合は、処理はステップＳ４０に移行し、
当該決裁申請書の起案者および当該決裁申請書の回付ル
ートに設定された者に対して、当該決裁申請書による決
裁が却下されたことが所定フォームの電子メールでそれ
ぞれ通知される。

【０１０３】これら、ステップＳ３８およびＳ３９の決
裁完了通知および決裁書類ファイル作成の処理、あるい
は、ステップＳ４０の決裁却下通知処理で、一連の決裁
処理が終了される。

【０１０４】組織変更などにより、変更前にある者によ
り閲覧可能だった決裁申請書が、変更後にはその者によ
り閲覧不可となる場合が有り得る。その場合、閲覧権限
が後任の者に委譲される。この実施の一形態による決裁
システムでは、決裁システム上で権限の委譲が行われ
る。図１９は、この権限の委譲を行うための閲覧権限委
譲画面２６０の一例の表示を示す。例えば、上述した図
８のフローチャートのステップＳ１６で、管理担当者に
より、上述の図１４の画面から決裁システムにアクセス
されると、ログイン時の情報に基づき人事・組織・電子
メールアドレスデータベース６３が検索され、検索結果
に基づきこの閲覧権限移譲画面２６０が表示される。

【０１０５】この閲覧権限委譲画面２６０の表示部２６
２には、組織変更などで当該管理担当者に閲覧権限が無
くなり、引き継ぐ組織に委譲すべき閲覧権限が一覧で表
示される。すなわち、当該管理担当者は、表示部２６２
に表示される組織コードを有する決裁申請書を閲覧等す
ることができない。表示部２６３には、当該管理担当者
が現在有する閲覧権限が一覧で表示される。当該管理担
当者は、これら表示部２６２および２６３に表示された
閲覧権限の中から、委譲すべき閲覧権限を選択し、選択
された閲覧権限を委譲先組織に委譲するように設定する
ことができる。委譲先組織は、組織にユニークに割り当
てられた組織コードや、所定の条件による組織検索の結
果に基づき、表示部２６４で設定することができる。委
譲ボタン２６１を押すことで、この閲覧権限移譲画面２
６０に対する設定内容が人事・組織・電子メールアドレ
スデータベース６３に反映され、閲覧権限の委譲が完了
される。

【０１０６】この実施の一形態による決裁システムで
は、上述したように、各担当者間の連絡が電子メールで
行われるようにしている。このときの、起案時から事後
連絡までの全ての回付先の電子メールアドレスは、担当
者それぞれの本人の所属および名前で登録される。実際
に電子メールの送信処理を行う場合には、全関連会社か
ら集めて統合した人事・組織・電子メールアドレスデー
タベース６３から回付先の情報が検索される。このと
き、回付先に指定された者が兼務しており、複数の電子
メールアドレスを有する場合は、回付先ルートに指定さ
れた所属（会社）の電子メールアドレスでメール連絡が
なされる。

【０１０７】なお、起案者が異動となり、人事・組織・
電子メールアドレスデータベース６３上で変更が発生さ
れた場合には、起案が取り下げられたものとして扱われ
る。この場合、異動となった起案者により起案された決
裁申請書が例えば決裁データベース５０Ａで検索され、
検索結果として得られた未決済の案件全てについて、そ
れまでの回付先で確認、承認された者に対して、起案が
取り下げられた旨が電子メールにより通知される。ま
た、回付ルート上の人が異動になった場合、人事・組織
・電子メールアドレスデータベース６３の変更が反映さ
れ、その人について、回付ルートのリスト表示より自動
的に削除される。

【０１０８】さらに、この実施の一形態による決裁シス
テムで送信される電子メールの文面は、宛先とされた者
の電子メールに指定される決裁申請書に対する立場、通
知される内容および宛先とされた者の所属の各情報に基
づき作成される。例えば、宛先とされた者が上長、管理
担当者、上長、事前確認者、決裁者、決裁者の秘書、事
後確認者および経理担当など、当該決裁申請書に対する
それぞれの立場に応じて内容が変えられる。また、通知
される電子メールの内容、すなわち、通知内容が起案時
の実際の決裁依頼内容や、通知が決裁、承認、確認およ
び取り下げの通知かで内容が変えられる。さらに、宛先
とされた者の所属、例えば宛先とされた者がＡ社、Ｂ社
およびＣ社の何れに所属するかにより、電子メールに記
述される問い合わせ先や所属の表示などが変えられる。

【０１０９】これらの電子メールのフォームは、テンプ
レートとしてメールフォーマットデータベース５２に格
納される。この決裁システムで決裁申請書を回付するた
めに電子メールが送信される際には、決裁申請書の回付
先ルートに設定された情報に基づき、回付先および回付
元の電子メールアドレス、名前および組織情報が人事・
組織・電子メールアドレスデータベース６３から検索さ
れる。また、上述の図８〜図１０で示すフローチャート
のどの段階で送信される電子メールであるかが判断され
る。さらに、回付される決裁申請書の決裁種類などが、
決裁データベース５０Ａが検索されて判断される。これ
らの判断結果およびデータベース６３の検索結果に基づ
きメールフォーマットデータベース５２が検索され、検
索結果に基づき電子メールの文面が自動的に生成され
る。

【０１１０】図２０および図２１に、このようにして自
動生成された電子メールの文面の例を示す。図２０は、
電子メールによる通常の決裁申請書を通知する一例の文
面を示す。この文面のうち、ヘッダ部２７０のうち件名
を除く部分は、回付先ルートに設定された内容に基づき
人事・組織・電子メールアドレスデータベース６３が検
索されて作成される。文面２７１と件名は、メールフォ
ーマットデータベース５２から検索されたテンプレート
に基づき作成される。この図２０の例では、この文面２
７１において当該決裁申請書の回付状況に応じて、図２
０中の例えば『上長の承認』の部分が差し替えられるよ
うになっている。このとき、差し替えられる内容は、役
職名ではなく、この決裁申請書に対する立場に基づく。

【０１１１】図２０において、文面２７２は、この電子
メールで通知される決裁申請書に関する情報が記述され
る。この文面２７２は、決裁データベース５０Ａからの
検索結果に基づき作成される。電子メールの表示画面上
で、この文面２７２中の先頭に「ＵＲＬ」と記された行
は、この決裁システム上に格納される所定のファイルの
ＵＲＬが記述されている。この行をメーラの表示上で所
定に指定することで、ブラウザソフトウェアが自動的に
起動され、ＵＲＬに基づき、決裁システムの所定のファ
イルがブラウザソフトウェアに読み込まれる。このと
き、ＵＲＬの記述に対して所定のパラメータが付加され
ることで、例えば決裁データベース５０Ａがパラメータ
に基づき検索され、当該電子メールにより回付される決
裁申請書がブラウザソフトウェア上に表示される。

【０１１２】なお、図２０において、文面２７３は、メ
ールフォーマットデータベース５２に格納されたテンプ
レートに基づく定型文である。

【０１１３】図２１は、電子メールによる、マル秘決裁
を行う決裁申請書を通知する一例の文例を示す。図２１
において、上述の図２０と共通する部分には同一の符号
を付し、詳細な説明を省略する。この場合は、ヘッダ部
２７０の件名表示および文２７２に記述される件名の部
分に、この電子メールがマル秘決裁の通知であることが
示される。また、文面２７１の「注意事項」には、マル
秘案件としてのアクセス制限に関する注意事項が記述さ
れている。

【０１１４】電子メール上で指定されるＵＲＬは、当該
電子メールの宛先であるユーザの当該電子メールで通知
される決裁申請書に対する権限に応じて、指定が異なら
される。例えば、ＵＲＬによりリンクされる決裁申請書
に対する「確認（決裁）できる」、「確認（決裁）はで
きないが、閲覧はできる」などのユーザの権限に応じ
て、指定が異ならされる。このＵＲＬにリンクされた決
裁システムのファイルにアクセスする際に、ＩＤおよび
パスワードを入力することで、ユーザは、当該電子メー
ルで通知された決裁申請書を閲覧可能とされる。このと
き、例えばＩＤおよびパスワードに基づき、アクセスし
たユーザの当該決裁申請書に対する権限が決裁システム
に判断され、権限に応じて決裁、却下などの所定の操作
を行うことができるようにされる。

【０１１５】より具体的には、電子メール上からユーザ
によりＵＲＬが指定されると、その情報が決裁システム
サーバ１０６に送信される。決裁システムサーバ１０６
では、送信された情報に基づき、例えばＣＧＩによるス
クリプトを用いて決裁データベース５０Ａから必要な情
報が取り出され、取り出された情報が所定に整形されて
ファイルが作成される。このファイルがユーザにアクセ
スされ、所定に整形された決裁申請書が閲覧可能とされ
る。

【０１１６】上述のような処理を行うことで、決裁申請
書の回付通知をプレーンテキストの情報のみで伝えるこ
とができ、電子メール処理による決裁システムおよびネ
ットワークの負担が軽くなる。これにより、処理がスピ
ードアップされ、また、端末装置側の処理が軽減され
る。

【０１１７】なお、モックアップなどの現物を添付して
の決裁においては、起案時に、決裁申請書に対して現物
が存在することを所定に指定することで、回付先を自動
的に記入した形でのカバーレターが出力される。図２２
は、このカバーレターの一例を示す。カバーレターは、
ネットワークや各端末装置などに所定に接続されたプリ
ンタ装置から印字され出力され、図２２に示されるよう
に、従来の紙による書類と同様の書式が用いられる。但
し、従来の紙による書類における押印箇所に対応する箇
所は、図に示されるように、押印不可の状態とされてい
る。これは、電子承認との紛らわしさを無くすためであ
る。

【０１１８】この実施の一形態による決裁システムで
は、送信される電子メールの種類と送信の宛先との関係
が所定に定義される。図２３は、この電子メールの種類
と送信宛先との一例の関連を示す。電子メールの宛先
は、決裁に対する立場に応じ、決裁の申請書作成者、申
請者、申請情報共有者、上長、管理部門、事前確認部
門、決裁者、事後連絡部門および経理担当が定義され
る。電子メールの種類は、承認／確認依頼、差し戻し通
知、却下通知および事後連絡の４種類が定義される。ま
た、それぞれの宛先の者に対し、代行者、秘書および共
有者が想定され、これら代行者、秘書および共有者それ
ぞれに対しても、送信される電子メールの種類が定義さ
れる。

【０１１９】なお、この例において、秘書は、この秘書
の上司に回付される決裁申請書の内容を確認し、上司の
承認／確認業務を促す役割の者をいう。代行者は、決裁
回付ルート上の上長による承認、管理担当者による承
認、事前確認者による確認の各ステップで昇任者または
確認者として設定されている者が何らかの理由で決裁シ
ステムにアクセスできないときや、承認／確認権限を委
譲している場合に、その者に代わって承認／確認業務を
行う役割の者をいう。また、共有者は、この共有者の上
司に回付される決裁申請書の内容を確認し、上司の承認
／確認業務を適宜補助する役割の者をいう。

【０１２０】電子メールの宛先および種類に応じて、メ
ール送信しない、メール送信する、代行者として承認／
確認を行っていた場合のみメール送信する、ならびに、
機密度が「回付ルートにのみ公開」の場合には送信しな
い、の４種類の送信レベルが定義される。送信レベル
は、図２３において、それぞれバツ印（×）、丸印
（○）、四角印（□）および三角印（△）で示されてい
る。また、図中の斜線は、回付ルート予定者本人にもメ
ール送信しない場合を示す。

【０１２１】すなわち、この決裁システムにおいて、回
付ルートに設定された宛先に電子メールが送信される際
に、この図２３に示される定義に従い、代行者、秘書お
よび共有者に対しても、当該電子メールがそれぞれ送信
される。

【０１２２】次に、上述した決裁申請書確認画面につい
て説明する。図２４は、この実施の一形態による決裁申
請書確認画面３００の一例を示す。決裁申請書確認画面
３００は、意志決定画面３０１、決裁申請書画面３０２
および回付状況画面３０３からなる。意志決定画面３０
１は、この決裁申請書確認画面３００の決裁申請書画面
３０２に表示されている決裁申請書に対する、承認／非
承認などの担当者の意思を入力する画面である。意志決
定ボタン３０４を押すことで、当該決裁申請書に対する
担当者の肯定的な意志が入力される。

【０１２３】この意志決定画面３０１は、図２５Ａ〜図
２５Ｅに例示されるように、決裁申請書に対して承認や
確認を行う者の立場に応じて、それぞれ異なる画面が用
意される。図２５Ａは、決裁申請書の申請者による承認
を行うための意志決定画面３０１Ａの例を示す。「申
請」と表示された意志決定ボタン３０４Ａを押すこと
で、当該決裁申請書が承認され、次のステップに当該決
裁申請書が回付される。ボタン３５０を押すことで、当
該決裁申請書の内容を修正することができる。ボタン３
５１Ａを押すことで、当該決裁申請書の作成者に差し戻
しを通知する電子メールが自動的に送信され、当該決裁
申請書が申請書作成者へ差し戻される。

【０１２４】図２５Ｂは、決裁申請書の申請者の上長に
よる承認を行うための意志決定画面３０１Ｂの例を示
す。「承認」と表示された意志決定ボタン３０４Ｂを押
すことで、上長により当該決裁申請書が承認され、次の
ステップに当該決裁申請書が回付される。ボタン３５１
Ｂを押すことで、当該決裁申請書の申請者および申請書
作成者に差し戻しを通知する電子メールが自動的に送信
され、当該決裁申請書が申請者および申請書作成者に差
し戻される。

【０１２５】図２５Ｃは、決裁申請書の管理部門（管理
担当者）による確認を行うための意志決定画面３０１Ｃ
の例を示す。「確認」と表示された意志決定ボタン３０
４Ｃを押すことで、管理担当者により当該決裁申請書が
確認され、次のステップに当該決裁申請書が回付され
る。これは、上述した図８〜図１０のフローチャートに
おけるステップＳ２０の処理に対応する。ボタン３５１
Ｃを押すことで、当該申請書の申請部門に差し戻しを通
知する電子メールが自動的に送信され、当該決裁申請書
が申請部門に差し戻される。

【０１２６】図２５Ｄは、事前確認者による承認を行う
ための意志決定画面３０１Ｄの例を示す。「異議なし」
と表示された意志決定ボタン３０４Ｄを押すことで、事
前確認者により当該決裁申請書が確認され、次のステッ
プに当該決裁申請書が回付される。これは、上述した図
８〜図１０のフローチャートにおけるステップＳ２６の
処理に対応する。当該決裁申請書に問題がある場合に
は、ボタン３５３が押される。これにより、当該決裁申
請書に対して異議有りフラグが設定され、当該決裁申請
書が次のステップに回付される。また、当該事前確認者
が当該決裁申請書に対して意見を述べる立場に無い場合
には、ボタン３５２を押すことで、当該決裁申請書に対
して確認の要無しとされる。

【０１２７】図２５Ｅは、決裁者による最終的な決裁を
行うための意志決定画面３０１Ｅの例を示す。当該決裁
申請書に示される案件の実効を最終的に承認する際に
は、「決裁」と表示された意志決定ボタン３０４Ｅが押
される。これは、上述した図８〜図１０のフローチャー
トにおけるステップＳ３６の処理に対応する。ボタン３
５４を押すことで、当該決裁申請書の起案者および各回
付先に対して、説明を要求する旨を通知する電子メール
が自動的に送信される。また、ボタン３５５を押すこと
で、当該決裁申請書が却下される。

【０１２８】なお、上述したボタン３５１Ａ、３５１Ｂ
および３５１Ｃ、ボタン３５３、ならびに、ボタン３５
５を押した際に、コメントの入力が可能なコメント入力
画面をさらに表示させることができる。

【０１２９】図２４の説明に戻り、決裁申請書画面３０
２には、当該決裁申請書の内容が表示される。決裁デー
タベース５０Ａからの検索結果に基づき、件名、決裁者
名、申請者名、目的や概要など決裁を行うために必要な
情報が決裁申請書画面３０２の対応する表示部分にそれ
ぞれ表示される。なお、「追加添付ファイルアップロー
ド」と表示されたボタンを押すことで、この決裁申請書
に対して添付ファイルを追加することができる。また、
「添付ファイル」の項目に示されているファイル名に基
づき、この決裁申請書に既に添付されたファイルを確認
することができる。例えば、この添付ファイル名の部分
には、対応する添付ファイルに対してリンクが貼られて
おり、この添付ファイル名の表示部分を例えばマウスな
どのポインティングデバイスで指定することで、当該添
付ファイルがアクセスされ、画面に表示される。

【０１３０】回付状況画面３０３には、当該決裁申請書
に設定された回付先ルートと、回付先ルートに設定され
た回付先のそれぞれにおける当該決裁申請書の回付状況
とが表示される。回付先ルートに基づき、決裁、事前確
認、管理担当確認、上長承認、申請者承認といった区分
と、それぞれの区分における承認者または確認者、承認
または確認を行った日付、承認または確認の結果が表示
部３０６に表示される。

【０１３１】表示部３０６には、さらに、各承認者また
は確認者が当該決裁申請書に対して付したコメントが表
示される。図２４では、コメントの冒頭部分だけが表示
され、この表示部分を例えばマウスなどのポインティン
グデバイスで指定することで、当該コメントの全体を表
示させることができる。さらにまた、表示部３０６に
は、回付中に添付された添付資料の有無が表示される。
この図２４の例では、回付先ルート上で添付資料が追加
された箇所にボタン３０７が設けられ、ボタン３０７を
押すことにより、添付資料を表示させることができる。
なお、添付資料がモックアップなどの電子データ化でき
ない資料である場合には、その旨記述した情報のみを表
示するようにしてもよい。

【０１３２】回付状況画面３０３では、「事前確認部門
追加」と表示されたボタン、「管理部門追加」と表示さ
れたボタンおよび／または「事後連絡部門追加」と表示
されたボタンを押すことで、新規に回付先を追加するこ
とができる。これらのボタンにより、管理担当者、事前
確認者および事後確認者をそれぞれ追加することができ
る。

【０１３３】次に、この実施の一形態による決裁システ
ムにおけるデータの論理的な構造について概略的に説明
する。データの論理構造は、決裁データベース５０Ａ、
５０Ｂ、人事・組織・電子メールアドレスデータベース
６３、決裁回付ルートテーブル５１、メールフォーマッ
トデータベース５２といった各種データベースおよびテ
ーブルがそれぞれ互いに、所定に関連付けられて構成さ
れる。

【０１３４】図２６〜図２９は、この決裁システムのデ
ータベースを構成する各種テーブルおよび各種テーブル
の関連を概略的に示す。なお、図２６および図２７にお
いて、符号Ｌ、Ｍは、互いに対応する符号に関連関係が
接続されることを示す。また、図２６および図２７にお
いて、テーブル間を接続する実線は、接続されたテーブ
ルが親子関係にある関係のテーブルであることを示し、
破線は、接続されたテーブルが親子関係の無い外部結合
のテーブルの関係にあるテーブルであることを示す。

【０１３５】テーブルの種類として、例えば決裁申請書
の１件毎に更新される通常のテーブルと、通常のテーブ
ルに対して基になるデータが格納されるマスタテーブル
とがある。図２６〜図２９の例では、内規適用グループ
テーブル、決裁種別テーブル、自動回付ルートテーブ
ル、ひな形テーブル、決裁区分テーブル、メッセージ種
別テーブルおよびアテンションメールテーブルがマスタ
テーブルであり、決裁申請書テーブル、回付ルートテー
ブル、決裁申請承認テーブルおよび関連決裁種別テーブ
ルが通常テーブルである。

【０１３６】先ず、マスタテーブルについて説明する。
内規適用グループテーブルは、会社コード、内規適用グ
ループコードのコード情報と、内規適用グループ名、シ
ステムオーナ管理フラグを含む。会社コードは、図示さ
れない会社テーブルと関連付けられ会社名が参照され
る。会社コード毎に内規適用グループコードが定義され
る。内規適用グループコードに基づき、内規の異なる会
社毎のテーブル情報が識別される。システムオーナ管理
フラグにより、どの会社のテーブルを操作することがで
きるかどうかが判断される。

【０１３７】決裁種別テーブルおよび決裁区分テーブル
が内規適用グループテーブルに対して子関係にあるテー
ブルである。それぞれ会社コードおよび内規適用グルー
プコードで関連付けられ、決裁種別テーブルにあっては
決裁種別コードおよび決裁種別名、決裁区分テーブルに
あっては決裁区分コードおよび決裁区分名が参照され
る。

【０１３８】決裁種別コードによって、例えば部長決
裁、役員会決裁などの決裁種別が内規適用グループコー
ド毎に定義される。同様に、決裁区分テーブルでは、決
裁区分コードによって決裁区分が内規適用グループコー
ド毎に定義される。

【０１３９】自動回付ルートテーブルおよびひな形テー
ブルが決裁種別テーブルに対して子関係にあるテーブル
である。自動回付ルートテーブルでは、会社コード、内
規グループ適用コードおよび決裁種別コードに対して、
自動回付ルートとして設定される社員とその社員が所属
する組織および会社が対応付けられる。

【０１４０】ひな形テーブルでは、会社コード、内規グ
ループ適用コードおよび決裁種別コードに対して、決裁
ひな形が対応付けられる。決裁ひな形は、決裁承認時に
押印表示を行う際のテンプレートである。例えば、上述
した図１７に示される決裁申請書の表示や、図２２に示
されるカバーレターのフォームデータがこの決裁ひな形
に相当する。

【０１４１】メッセージ種別テーブルは、この決裁シス
テムで用いられるメッセージ情報が格納される。メッセ
ージ情報は、メッセージコードによりメッセージ種別テ
ーブルから引き出される。アテンションメールテーブル
は、上述した図８〜図１０のフローチャートにおける各
承認、確認を通知する電子メールの内容が、承認種別、
承認状況毎に格納される。

【０１４２】通常テーブルについて説明する。決裁申請
書テーブルは、この決裁システム上で実際に作成された
決裁申請書の情報が格納される。決裁申請書テーブルに
格納されたそれぞれの決裁申請書は、会社コードと申請
番号（決裁ＩＤ）により識別される。図２７では一部し
か示されていないが、決裁申請書の各項目に入力される
情報がそれぞれ決裁申請書テーブルに格納される。決裁
申請書テーブルは、上述した決裁区分テーブルと外部結
合の関係にあり、例えば決裁申請書テーブル中の項目決
裁区分に基づき、決裁申請書テーブルと決裁区分テーブ
ルとが結合され、決裁申請書から決裁区分名が参照され
る。

【０１４３】回付ルートテーブル、決裁申請承認テーブ
ルおよび関連決裁種別テーブルが決裁申請書テーブルに
対して子関係にあるテーブルである。回付ルートテーブ
ルは、会社コードおよび申請番号で識別され、決裁申請
書毎の回付ルートが格納される。回付ルートテーブルに
は、申請番号で識別される決裁申請書において回付ルー
トに予定されている社員の情報および／または回付ルー
トに設定されている社員の情報が格納される。名前、所
属組織コード、所属会社コード、電子メールアドレスな
どが社員情報として格納される。

【０１４４】決裁申請承認テーブルは、申請番号で関連
付けられる決裁申請書に対する承認情報が格納される。
承認時に付されたコメントも格納される。関連決裁種別
テーブルは、申請番号で関連付けられる決裁申請書に対
する決裁種別が決裁種別コードにより格納される。決裁
種別テーブル中の決裁種別コードに基づき、関連決裁種
別テーブルと決裁種別テーブルとが結合され、決裁種別
テーブルから決裁種別名が参照される。

【０１４５】図２８は、メッセージ種別テーブルの一例
を示す。メッセージ種別テーブルには、この決裁システ
ムにおいて各端末に表示される様々なメッセージが格納
される。メッセージは、メッセージコードによりシステ
ムから呼び出され、表示される。図２９は、アテンショ
ンメールテーブルの一例を示す。アテンションメールテ
ーブルには、この決裁システムによりやりとりされた電
子メールが格納される。

【０１４６】なお、上述では、この実施の一形態による
決裁システムを説明するために重要なテーブルおよびテ
ーブル内の項目を抜き出して図２６〜図２９に示し、ま
た説明している。実際には、決裁システムのデータベー
スは、会社情報、会社毎の組織および社員情報に関する
情報、決裁申請書に対する閲覧権限に関する情報、決裁
を行う会議体に関する情報、決裁システムにおいて各端
末に公開されるファイルに関するＵＲＬなどの情報など
のテーブルを、さらに有する。

【０１４７】また、回付先ルートの変更は、起案者が行
うことができる。この場合、回付先ルート上で既に確
認、承認を行った者と、変更対象者、すなわち変更前お
よび変更後のそれぞれに該当する者に対して、回付ルー
トが変更になった旨を通知する電子メールが自動的に送
信される。このため、回付先ルートの変更を行うために
起案を取り下げ、変更後の回付先ルートで新たに起案を
行う必要がない。また、回付先ルート変更の通知が決裁
システム上で自動的に送信されるため、回付先ルート変
更のために別途に連絡を行う必要がない。

【０１４８】なお、既に述べたように、回付先ルートの
設定は、起案時に起案者の所属および起案種別（決裁種
別）に基づき回付ルートテーブルから決裁申請書の回付
先が検索され、検索された回付先が画面上に表示され
る。回付先ルートは、起案者や管理担当者に当該決裁申
請書が回付された際に修正や追加され、確定される。回
付ルートテーブルは、決裁システムの管理者により、各
会社毎に設定、変更が行われる。

【０１４９】

【発明の効果】以上説明したように、この発明による決
裁システムでは、関連会社の人事、組織情報や電子メー
ルアドレスが１箇所で統合的に管理されるため、大会社
などで良く発生する兼務においても、それぞれの立場か
ら起案や決裁を行うことができるという効果がある。

【０１５０】また、この発明の実施の一形態では、秘
書、代行者、情報共有者に対する権限がそれぞれ設定さ
れているため、決裁処理について、例えば事前確認者な
どにおいて本人が直接的に関与しなくても代行処理を行
わせることが可能であるという効果がある。

【０１５１】さらに、この発明では、決裁申請書の回付
通知が電子メールで送信され、この電子メールから当該
決裁申請書にアクセスし閲覧することができるので、回
付ルート上に多数の人が関係していても、処理が直列処
理ではなく並列処理とされ、起案から決裁までを迅速に
行える効果がある。

【０１５２】さらにまた、この発明の実施の一形態で
は、回付ルートが決裁申請書毎にテーブル化されている
と共に、回付ルートが変更、削除された場合には、既に
回付された者と変更前および変更後の変更対象者とに対
して、変更された旨が自動的に通知される。そのため、
決裁申請書の回付途中でも回付ルートの変更や削除、回
付先の追加を行うことができるという効果がある。

【０１５３】また、この発明の実施の一形態では、各承
認、確認段階に決裁申請書が回付されることを通知する
電子メールのフォームが自動的に作成される。このと
き、電子メールの内容が、送信される相手の立場、決裁
の状況などに応じたものとされるため、この通知電子メ
ールを受け取った者にとって、メッセージが非常にわか
りやすいという効果がある。

【０１５４】さらに、この発明の実施の一形態では、決
裁申請書の回付通知がプレーンテキストによる電子メー
ルでなされ、実際の決裁申請書は、電子メール中に記述
されたＵＲＬからリンクされるようになっており、これ
により決裁処理などが行えるため、処理に要する時間が
短くて済むと共に、ネットワークに対する負荷が軽いと
いう効果がある。

【図面の簡単な説明】

【図１】実施の一形態に適用可能な業務フローを概略的
に示す略線図である。

【図２】この発明による決裁システムを実現するための
決裁データベースと決裁のフローとの相関を概略的に示
す略線図である。

【図３】人事・組織情報と電子メールアドレスを統合
し、一元的に管理する様子を概略的に示す略線図であ
る。

【図４】人事・組織情報と電子メールアドレスを統合
し、一元的に管理する様子をより具体的に示す略線図で
ある。

【図５】データベースを統合する方法を説明するための
略線図である。

【図６】データベースを統合する方法を説明するための
略線図である。

【図７】実施の一形態による決裁システムの一例のハー
ドウェア的な構成を示す略線図である。

【図８】実施の一形態の決裁システムによる一例の決裁
処理を説明するためのフローチャートである。

【図９】実施の一形態の決裁システムによる一例の決裁
処理を説明するためのフローチャートである。

【図１０】実施の一形態の決裁システムによる一例の決
裁処理を説明するためのフローチャートである。

【図１１】決裁申請書を作成する決裁申請書作成画面の
一例を示す略線図である。

【図１２】決裁申請書の回付ルートを設定する回付ルー
ト設定画面の一例を示す略線図である。

【図１３】新規に回付先を追加する手順について概略的
に説明するための図である。

【図１４】兼務している部署のうちどの部署を処理対象
として決裁システムにアクセスするかを選択する一例の
画面を示す略線図である。

【図１５】未承認決裁を確認するための未承認決裁確認
画面の一例を示す略線図である。

【図１６】決裁完了を通知する電子メールの一例のフォ
ームを示す略線図である。

【図１７】決裁申請書の各端末への一例の表示を示す略
線図である。

【図１８】説明を要求する旨が記述された電子メールの
一例のフォームを示す略線図である。

【図１９】権限の委譲を行うための閲覧権限移譲画面の
一例の表示を示す略線図である。

【図２０】電子メールによる通常の決裁申請書を通知す
る一例の文面を示す略線図である。

【図２１】電子メールによるマル秘決裁を行う決裁申請
書を通知する一例の文例を示す略線図である。

【図２２】決裁申請書に現物が添付される場合の一例の
カバーレターを示す略線図である。

【図２３】電子メールの種類と送信宛先との一例の関連
を示す略線図である。

【図２４】実施の一形態による決裁申請書確認画面の一
例を示す略線図である。

【図２５】決裁申請書確認画面中の意志決定画面の例を
示す略線図である。

【図２６】決裁システムのデータベースを構成する各種
テーブルの関連を概略的に示す略線図である。

【図２７】決裁システムのデータベースを構成する各種
テーブルの関連を概略的に示す略線図である。

【図２８】決裁システムのデータベースを構成する各種
テーブルを概略的に示す略線図である。

【図２９】決裁システムのデータベースを構成する各種
テーブルを概略的に示す略線図である。

【符号の説明】

５０Ａ，５０Ｂ・・・決裁データベース、５１・・・決
裁回付ルートテーブル、５２・・・メールフォーマット
データベース、６３・・・人事・組織・電子メールアド
レスデータベース、１００，１１０，１２０・・・ネッ
トワーク、１０６・・・決裁サーバ、２００・・・決裁
申請書作成画面、２２０・・・回付ルート設定画面、２
５０，２５１・・・ＵＲＬ、２６０・・・閲覧権限委譲
画面、３００・・・決裁申請書確認画面、３０１・・・
意志決定画面、３０２・・・決裁申請書画面、３０３・
・・回付状況画面、３０４・・・意志決定ボタン

Claims

【特許請求の範囲】

【請求項１】それぞれ独立した決裁権を有する複数の
組織に跨って決裁を行うようにした決裁システムにおい
て、それぞれ独立した決裁権を有する複数の組織間で通信を
行うと共に、上記複数の組織それぞれの内部で通信を行
うネットワーク手段と、組織の人事および組織情報、ならびに、上記組織に所属
する者の上記ネットワーク手段上でのアドレス情報を、
上記複数の組織について共通に格納する第１のデータベ
ースと、上記複数の組織それぞれの決裁ルール情報を格納する第
２のデータベースと、決裁情報を格納する決裁データベースと、上記第１のデータベースに格納された上記組織の人事お
よび組織情報、ならびに、上記アドレス情報と、上記第
２のデータベースに格納された上記決裁ルール情報とに
基づき、上記決裁データベースに格納された上記決裁情
報の回付先を設定する決裁情報回付先設定手段と、上記決裁情報回付先設定手段により設定された上記決裁
情報の回付先に、上記決裁データベースに格納された上
記決裁情報を上記ネットワーク手段を介して回付する決
済情報回付手段とを備えることを特徴とする決裁システ
ム。
【請求項２】請求項１に記載の決裁システムにおい
て、上記決裁情報回付先設定手段により上記決裁情報の起案
時に設定された上記決裁情報の回付先の設定を、決裁情
報の回付先で変更可能としたことを特徴とする決裁シス
テム。
【請求項３】請求項２に記載の決裁システムにおい
て、上記決裁情報の回付先の設定が上記変更された場合、上
記決裁情報の回付先の設定が変更された旨を、該変更前
の上記決裁情報の回付先のそれぞれと該変更後の上記決
裁情報の回付先のそれぞれとに、上記アドレス情報に基
づき上記ネットワーク手段によって通知するようにした
ことを特徴とする決裁システム。
【請求項４】請求項１に記載の決裁システムにおい
て、上記決裁情報を該決裁情報の起案者から取り下げ可能と
したことを特徴とする決裁システム。
【請求項５】請求項４に記載の決裁システムにおい
て、上記決裁情報の起案者により上記決裁情報が取り下げら
れた場合、上記決裁情報が取り下げられた旨を、上記決
裁情報を既に確認した上記決裁情報の回付先のそれぞれ
に、上記アドレス情報に基づき上記ネットワーク手段に
よって通知するようにしたことを特徴ととする決裁シス
テム。
【請求項６】請求項１に記載の決裁システムにおい
て、上記第１のデータベースに格納された情報に基づき、上
記決裁情報の起案者が異動になったとされた場合には、
未決裁の該起案者による上記決裁情報が全て取り下げに
なるようにしたことを特徴とする決裁システム。
【請求項７】請求項１に記載の決裁システムにおい
て、上記決裁情報回付先設定手段では、上記第１のデータベ
ースに格納された情報に基づき、上記人事および／また
は上記組織の変更に対応して、上記回付先の当人の後任
の者を該回付先の当人の代理人として登録できるように
したことを特徴とする決裁システム。
【請求項８】請求項１に記載の決裁システムにおい
て、上記決裁情報回付手段は、上記決裁情報を上記回付先に
回付する際に、該決裁情報が該回付先に回付される旨の
通知を、該回付先に応じたフォームで、上記ネットワー
ク手段を介して該回付先に送信することを特徴とする決
裁システム。
【請求項９】請求項８に記載の決裁システムにおい
て、上記決裁情報回付手段は、上記通知に対して上記決裁デ
ータベースに格納された上記決裁情報へのアクセス手段
を埋め込んで該通知を送信し、該通知の受信側で上記ア
クセス手段を用いることで自動的に上記決裁情報にアク
セスできるようにしたことを特徴とする決裁システム。
【請求項１０】請求項９に記載の決裁システムにおい
て、上記決裁情報回付手段は、上記第１のデータベースの情
報に基づき、上記回付先の者の権限に応じて上記決裁情
報に対する上記アクセスを制限するようにした上記アク
セス手段を上記通知に埋め込むことを特徴とする決裁シ
ステム。
【請求項１１】請求項１に記載の決裁システムにおい
て、上記決裁データベースは、上記複数の組織の上記決裁情
報が単一のハードウェア上に格納されると共に、上記複
数の組織毎の上記決裁情報が上記単一のハードウェア上
でそれぞれ論理的に分けられて格納されることを特徴と
する決裁システム。
【請求項１２】請求項１に記載の決裁システムにおい
て、上記決裁情報回付先設定手段は、上記決裁情報に対する
立場に基づき該決裁情報の上記回付先を設定することを
特徴とする決裁システム。
【請求項１３】請求項１２に記載の決裁システムにお
いて、上記決裁情報回付先設定手段は、複数の上記決裁情報に
対する立場が同一の者を上記決裁情報の回付先に設定し
て、上記複数の決裁情報に対する立場が同一の者に対し
て並列的に上記決裁情報を回付するようにしたことを特
徴とする決裁システム。
【請求項１４】請求項１に記載の決裁システムにおい
て、上記決裁情報が、上記決裁情報回付先設定手段により該
決裁情報に対して決裁直前の確認を行う事前確認者とし
て設定された全員に問題無いとして確認されれば、上記
決裁情報回付先設定手段により上記決裁情報に対する決
裁者として設定された者の決裁が無くても上記決裁情報
に対して決裁がなされたと見なすようにしたことを特徴
とする決裁システム。
【請求項１５】請求項１に記載の決裁システムにおい
て、上記決裁情報に対して下された決裁に関する情報を保存
する処理をバッチ処理によって行うようにしたことを特
徴とする決裁システム。
【請求項１６】請求項１に記載の決裁システムにおい
て、上記決裁情報回付設定手段は、上記複数の組織に跨って
上記回付先を設定することができるようにしたことを特
徴とする決裁システム。