JPH02281369A - 決裁処理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 （産業上の利用分野） 本発明は決裁処理方式に係り、特に複数の組織ＭＷＪを
有する組織で複数の決裁者の裁定を経て初めて効力を有
する決裁文履の裁定処理をオンラインシステムを用いて
行なう決裁処理方式に関する。

〔従来の技術〕

従来、オンライン計算機システムを用いた決裁処理方式
として、第５図に示す如き端末間のメール回覧機能を利
用した方式（これを以下、「メ−ル決裁処理方式、１と
いう）が知られている。同図中、１１は通信網で、端末
１２〜１７その他多数の端末からのデータの双方向通信
を可能にしている。

この通信網１１は複数の職権階層を有する組織に設けら
れており、ここでは−例として株式会社の総務担当が起
案した決裁文書について、総務課長、総務部長及び社長
の裁定を経る場合について説明する。＊ｉ担当は決裁文
書を作成し、これをメール回覧として送信する際に、決
裁順序（回覧層）を指定して端末１２から通信網１１へ
送信する。ここでは、決裁順序は総務課長、総務部長。

社長であるものとする。

これにより、メール（決裁文書）は最初に指定された決
裁者である総Ｓ諌艮の利用する端末１５へ■で示す如く
配送され、総務課長の決裁後に次の決裁者である総務部
長が利用する端末１６へ■で示す如く回送される。

以下、上記と同様にして順次決裁が進み最終決裁者であ
る社長が利用する端末１７へ■で示す如くメールが目送
され、社長の決裁後に決裁文書処理担当へ送信されて一
連の処理を終える。

このように、各端末１２〜１７上のメール回覧機能を土
台としてその上に決裁機能を構築した構成のメール決裁
処理方式においては、端末１２〜１７ｆｉｌのメール回
覧機能を用いているため、比較的簡単にサービスが構築
でき、また決裁文書の自動送信が可能であるなどの利点
がある。

また、従来の決裁処理方式の他の例として、オンライン
センタ上の業務プログラムで決裁文書を集中的に管理・
処理する方式（これを以下、「業務プログラム決裁処理
方式、１という）が知られている。この業務プログラム
決裁処理方式は第６図に示す如き構成とされており、通
信網２ｏにより端末２１〜２６並びにオンラインセンタ
２７が夫々双方向通信可能なように接続されている。

この業務プログラム決裁処理方式では、オンラインセン
タ２７に業務プログラム２８を配置し、決裁文書及び決
裁者の一括管理・処理を行なう。

すなわち、前記第５図と同様に株式会社の総務担当が起
案した決裁文書について、総務課長、総務部長及び社長
の裁定を経る場合を例にとって第６図と共に説明するに
、端末２１から通信網２０へ送信された決裁文１１２９
はオンラインセンタ２７へ配送される。オンラインセン
タ２７内の業務プログラム２８には決裁利用者のデータ
、決裁書順序のデータ、決裁伝票ファイルなどが予め格
納されており、オンラインセンタ２７は入力された決裁
文書２９の様式から、その様式に適合した決裁書順序に
従い、第６図にΦ〜ので示す如く総務課長の利用端末２
４．総務部長の利用端末２５の順で、順次メール（この
場合、決裁文Ｉ２９）の双方向転送を行ない、最後に■
で示す如く社長の利用端末２６へメールを配送する。

（発明が解決しようとする課題） しかるに、第５図に示した従来のメール決裁処理方式は
、以下のような８８題点がある。

■　決裁文書の作成送信時に、その都度、回覧順序を指
定する必要がある。

■　決裁がどこまで遊んでいるか等の決裁状況の同い合
わせが困難。

■　決裁文書が途中で紛失する可能性があるが、紛失場
所の特定が困難。

■　決裁処理に関しての統計情報収集分析などの処理が
困難。

■　決裁者の短期不在、異動等があっても、メール送信
後は決裁順序の変更が困難。

このため、メール決裁処理方式では重要文書の決裁には
殆ど利用されていないのが実情である。

一方、第６ＩＯに示した従来の業務プログラム決裁処理
方式では、業務プログラム内で処理に必要なすべてのデ
ータ及び処理結果を管理するため、上記■から■の課題
は解決できるものの、なお以下のようなｆｉ題点がある
。

■　ＩＩＩＩｌｌ再糧・人事異動などにより決１３１１
１１１序が変わると、その都度業務プログラムの変更が
必要になる。

■　予めシステムに登録されていた決裁者が不在でも代
理人が決裁できるなどの、より柔軟な決裁処理ができな
い。

本発明は以上の点に鑑みてなされたもので、複数の猫１
１階層を有する組織で複数の決裁者の裁定を経て初めて
効力を有する決裁文書を作成するためのオンライン決裁
処理方式において、組織改編。

人事異動の管理、及び文書の決裁状態などを共通機能と
してシステム側で提供することにより、決裁関連情報の
変更があっても業務プログラムの改造を必要とせず、シ
ステム固有の業務プログラムの作成規模を軽減する決裁
処理方式を提供することを目的とする。

〔課題を解決するための手段〕

上記目的達成のため、本発明は第１図の原理構成図に示
す如く、業務プログラム３１と電子決裁システム３２と
より構成したものである。業務プログラム３１は端末３
３との入出力及びオンラインシステム固有の処理を分担
する。

電子決裁システム３２は決裁処理に関係する人間の決ｍ
ｒｔｔ達情報３４．複数の職権階層を有する１ｆｌ織の
１１＃１構成情報３５．及び決裁シナリオ情報３６を保
持すると共に、決裁ステータス情報作成手段３７及び決
裁ステータス情報送受信手段３８を有し、上記の各保持
情報３４〜３６に基づき端末３３より業務プログラム３
１を介して入りＪされた起票者の入力情報に応じた決裁
ステータス情報の作成、更新及び送受信を行なう。

上記の決裁ステータス情報送受信手段３８は作成された
決裁ステータス情報を決裁者の利用端末３３へ決裁依頼
通知を行なってからその決裁通知の返送を受取り、決裁
ステータス情報の更新を行なうことを複数の決裁者の利
用端末３３に対し所定の順序で順次行なうことを繰り返
す。

〔作用〕

本発明では決裁者の個人名１個人コード、所属名、所属
コード、役職、役職コードからなる決裁関連情報３４と
、部と課の包含関係、指揮命令監督権の上下関係等、組
織の階層構成を表わす組織構成情報３５と、決裁処理を
必要とする役職、順番を決裁文書様式（すなわち決裁種
別）毎に規定した決裁シナリオ情報３６とを、業務プロ
グラム３１から独立した電子決裁システム３２に保持す
る。

また、決裁文書の決裁ステータス情報（すなわち、どの
決ａ者まで処理が済んでいるか、決裁の可否の情報）も
業務プログラム３１とは独立に電子決裁システム３２の
決裁ステータス情報送受信手段３８内に保持する。

電子決裁システム３２ではこれらの情報３４〜３６に基
づいて、起票者により作成された入力情報（決裁文書様
式）が端末３３から業務プログラム３１を介して入力さ
れたとき、決裁ステータス情報作成手段３７により当該
起票基の所属コードと組織構成情報及び決裁シナリオ情
報から決裁者順序の情報を求め、決裁ステータス情報と
して作成し、これを決裁ステータス情報送受信手段３８
及び業務プログラム３１を介して端末３３との間で所定
の端末類に送受信を行ない、決裁ステータス情報送受信
手段３８により決裁ステータス情報の更新や保持を行な
う。

これにより、決裁文書の管理は電子決裁システム３２で
行なわれることになり、端末３３の利用者及び業務プロ
グラム３１は決裁文書様式を指定するだけでよく、組織
の構成（誰に決裁文書を回せばよいか）や決裁状況の管
理（どのような順序でどこまで決裁が進んでいるか）な
どに関しては全＜Ｒ＊Ｌ、、ないで済む。

また、従来は電子決裁システム３２で保持している情報
３４〜３６を業務プログラム３１が保持すでいたため、
適用システム側々に業務プログラムを開発したり、組織
変更の度に業務プログラムを変更する必要があったが、
本発明では人事異動や組織改編に関しては組織構成情報
３５及び異動した人の決裁関連情報３４のみの修正だけ
でよく、業務プログラム３１の開発、変更は不要である
という特徴がある。

（実施例） 第２図は本発明方式の一実施例の構成及び処理ＩＩ要説
明図を示す。同図中、第１図と同・−構成部分には同一
符号を付しである。本実施例は株式会社の総務担当が起
案した決裁文書について、総務課長、総務部長及び社長
の決裁を経る場合の例である。

オンラインシステムのセンタ上には、システムプログラ
ム（図示せず）の他、第２図に示す如く業務プログラム
３１及び電子決裁システム３２が配置されている。第２
図において、業務プログラム３１は端末３３−１〜３３
−ｎとの入出力及びオンラインシステム固有の処理（例
えば、伝票アクセス権チエツク、伝票内データのチエツ
ク及び統計データベースへの登録集４等）を分担してい
る。

また、電子決裁システム３２は前記した決裁関連情報３
４及び組織構成情報３５を格納している利用者・組織デ
ータベース（以下ｒＤＢＪと記す）４１、前記決裁シナ
リオ情報３６を格納している決裁シナリオＤＢ４２．こ
れらＤＢ４１及び４２を制御して前記決裁ステータス情
報作成手段３７を実現する制御用プログラム４３．並び
に前記した決裁ステータス情報送受信手段３８を実現す
るためのＤＢファイル４４及び処理プログラム４５など
からｌＩ４成される。

なお、Ｄ　Ｂ　７　ｙイル４４は決裁ステータス、決裁
メール、一般メールなどのＤＢファイルである。

また、利用者・組織０８４１はシステム共通のＤＢを使
用してもよい。

次に本実施例の動作について第３図の７［１−チャート
及び第２図及び後述の第４図と共に説明する。電子決裁
システム３２はまず第３図のステップ１０１で利用者情
報（所属コード、氏名コード。

役職コード等）と伝票様式番号及び伝票管理のためのそ
の他の情報が起Ｍ者から通知される。ここでは、第２図
に示す端末３３−１を操作する総務担当が起票者で、自
己のＩＤコードＰａ等の利用者情報及び伝票様式番号“
１”などが端末３３−１より■で模式的に示す如く業務
プログラム３１を介して電子決裁システム３２に通知さ
れる。

電子決裁システム３２はこの通知を受取ると第３図のス
テップ１０２へ進み、決裁ステータス情報の作成を行な
う。この決裁ステータス情報の作成について第４図と共
に更に詳細に説明するに、同図中、決裁シナリオ０８４
２中に格納されている複数の決裁シナリオ情報の中から
入力伝票様式番号“１”に対応した決裁シナリオ情報５
０が読み出される。

すなわち、決裁処理は誰が決裁をしなければならなりか
が予め伝票様式（文園様式又は決裁種別）毎に決まって
いるが、決裁のパターンはいくつかあるのが通例である
。例えば、伝票様式１については課長、所長及び社長、
伝票様式２については課長補佐９課長及び部長、伝票様
式３については研究室長、研究所長及び研究開発本部長
というように、決裁文書である伝票の様式によって決裁
者は異なるが、伝票がどの課から提出されたものであっ
ても、決裁者の役職は伝票様式が同じならば同じである
。そこで、本実施例では伝票様式毎の役職クラスの決裁
順序（課長１部長０社長の順に決裁するということ）を
決裁シナリオ情報とじて実現する。

また、第４図中、利用者・組織ＤＢ４１には複数の職権
ｌ＠層における複数の決裁者の決１ｌｌＩＱ達情報と組
織構成情報とが格納されており、この中から入力伝票様
式番号“１”に対応した情報（総務課長のコードＰ＋　
、総務部長のコードＰ２及び社長のコードＰｓ）が読み
出される。これにより、第４図に５１で示す如き決裁ス
テータス情報が作成される。

この決裁ステータス情報５１は入力伝票様式番号“１”
に対応して、総務課長Ｐ１→総務部長Ｐ２→社長Ｐ３の
順で決裁されるべきことを示しており、また代行決裁の
可否１代行法ｌ１者名等の情報が含まれ、また決裁者の
決裁が可決か否決かである旨の情報（これｔＳ後の決裁
の都度農き込まれる）も含まれる。

このようにして決裁ステータス情報５１が第４図及び１
１２図に■で模式的に示す如く作成されると、電子決裁
システム３２は次に第３図のステップ１０３へ進み最初
の決裁者である総務課長の利用端末３３−２へ第２図に
■で模式的に示す如く決裁依頼通知を行なった後、端末
３３−２から総務課長の決裁（ここでは−例として第２
図に■で模式的に示す如（総務課長による“可決”の決
裁）の通知を業務ブＯグラム３１を介して受取る（第３
図中、ステップ１００゜ この返送された情報中には総量ｉ長のコードＰ＋及び決
裁の可否が含まれており、電子決裁システム３２は第３
図のステップ１０５で決裁者（この場合、総ａ課長）に
代わり別の人により代行決裁が行なわれたか否かを判定
し、本人が決裁した場合には続くステップ１０６で決裁
ステータス情報を第２図に■で模式的に示す如く、総務
課長の部分の決裁の可否や決裁者の更新を行なう。なお
、ステップ１０５で代行決裁と判定された場合は、ステ
ップ１０７によりその代行者が許可された者かどうかな
どに基づいて代行決裁が有効か否かの判定を行ない、有
効な場合は上記ステップ１０６へ進む。

続いて、ステップ１０Ｂで上記決裁が可決か否かの判定
を行ない、可決の場合はステップ１０９で決裁者が最終
決裁者（ここでは社長）であるか否かの判定が行なわれ
る。この時点では総務課長から“可決”の決裁の通知が
あっただけなので、続いてステップ１１Ｇ八道み、次の
決裁者である総務部長の利用端末へ業務プログラム３１
を介して決裁依頼通知を行なプた後、ス・アップ１０４
へ進む。

以下、上記と同様にしてステップ１０４〜１１０の処理
が繰り返され、総務部長からの可決の決裁通知→その旨
の決裁ステータス情報の更新→社長の利用端末３３−ｎ
への決裁依頼通知−→社長の利用端末３３−ｎより可決
の決裁通知（第２図に■で模式的に示す）→その旨の決
裁ステータス情報の更新の順で順次行なわれると、ステ
ップ１０９で最終決裁者の判定が行なわれ、次のステッ
プ１１１で起票者である総務担当の端末３３−１へ処理
完了通知が行なわれ（第２図に■で模式的に示す）ステ
ップ１１３で処理終了となる。

なお、ステップ１０７で代行決裁が無効と判定された場
合及びステップ１０８で決裁が否決であった場合には、
ス゛アップ１１２へ進んでその旨の通知が起票者へ通知
され、その後処理終了となる（ステップ１１３）。

このように、本実施例によれば、組織の改編。

利用者の異動などが電子決裁システム３２で管理され、
業務プログラム３１は決裁の順序９文書の決裁順序等を
意識する必要がない。このため、決裁処理に叫し業務ブ
０グラム３１は組織変更９人事異動等に左右されず、変
更が不要であり、また極めて小規模で済む。

また、総務担当は伝票様式番号等だけを通知するだけで
良いので、操作性が極めて良い。更に、本実施例では代
行決裁が可能であるので、決裁者の短期不在、異動等が
あっても、決裁文書（伝票）送信後でも決裁処理が可能
である。

なお、本発明は上記の実施例に限定されるものではなく
、決裁伝票の様式の数９組織の構成名称。

決裁関連情報の数、各種情報の形式、大きさ、及び決ａ
ｖｉｒ係等については実施例以外でも本発明を適用でき
ることは勿論である。

〔発明の効果〕

上述の如く、本発明によれば、複数のｌｌＪＩｖＡ層を
有する組織で複数の決裁者の裁定を経て初めて効力を有
する決裁文書を作成するためのオンラインシステムのセ
ンタ上の業務プログラムは、組織の４１１ＩＪｉｌｃや
決裁状況の管理等から開放されるため、業務プログラム
の開発量が極めて小規模で済むと共に、組織変更、異動
人事に対応した業務プログラムの開発、変更は全く不要
にできる。更に、本発明では起票者が特別の決裁順序等
の指示をしなくても、入力情報に応じた所望の決裁処理
が自動的に実行されるため、操作性を大幅に向上するこ
とができる等の特長を有するものである。

【図面の簡単な説明】

第１図は本発明方式の原理構成図、第２図は本発明方式
の一実施例の構成及び処理概要説明図、第３図は本発明
方式の一実施例の動作説明用フローチャート、第４図は
決裁ステータス情報の生成説明図、第５図は従来方式の
一例の構成図、第６図は従来方式の他の例の構成図であ
る。 ３１−・・業務プログラム、３２−・・電子決裁システ
ム、３３−・・端末、３４−・・決裁関連情報、３５−
・・組ｔｓ構成情報、３６・軸決裁シナリオ情報、３７
・・・決裁ステータス情報作成手段、３８・−決裁ステ
ータス情報送受信手段。 本発明方式の原理構成図 第１図 本発明方式の一実施例の動作説明用７０チヤ ト 従来方式の 例の構成図

Claims (1)

1. 【特許請求の範囲】 複数の職権階層を有する組織の複数の階層の各決裁者の
   裁定を経て初めて効力を有する決裁文書の決裁処理をオ
   ンラインシステムで行なう決裁処理方式において、 端末との入出力及びオンラインシステム固有の処理を分
   担する業務プログラムと、 決裁処理に関係する人間の決裁関連情報、組織構成情報
   及び決裁順序関係を示す決裁シナリオ情報を保持すると
   共に、これらの保持情報に基づき前記端末より前記業務
   プログラムを介して入力された入力情報に応じた決裁ス
   テータス情報の作成、更新及び送受信を行なう電子決裁
   システムとよりなり、 該電子決裁システムは該決裁ステータス情報を作成する
   決裁ステータス情報作成手段と、作成された該決裁ステ
   ータス情報に基づき決裁者の利用端末へ決裁依頼通知を
   行なってからその決裁通知の返送を受取り該決裁ステー
   タス情報の更新を行なうことを複数の決裁者の利用端末
   に対し所定の順序で順次繰り返す決裁ステータス情報送
   受信手段とを有することを特徴とする決裁処理方式。