JPH10214113A - 掲示板型データベースを用いた業務処理システム及びその処理方法 - Google Patents

Abstract

(57)【要約】 【課題】複数の作業工程のシーケンスから構成される業
務処理の流れにおいて、工程から工程へと通常の伝票を
単位とするデータの伝達方法を改善し、作業効率を向上
させる。 【構成】掲示板データベース１１は、一連の業務プロセ
スに関連するすべてのデータ項目の内容を集約して格納
し、関連するすべての作業担当者がクライアント２を介
して掲示板の形式で共有する。状態遷移ルール１２は、
作業工程の各々についてデータ入力を完了すべきデータ
項目を設定する。状態監視部３は、掲示板データベース
１１及び状態遷移ルール１２を参照して現在作業中の工
程が規定のデータ入力を完了したとき、次の作業工程に
遷移させ、関連するクライアントに状態遷移を通知し、
また各作業工程のデータ入力完了期限を設定する状態遷
移期限ルール１３を参照して処理期限が迫ったとき、関
連するクライアント２に通知する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の作業工程の
シーケンスから構成されるワークフローにおいて、各作
業工程が業務処理の結果として電子計算機にデータ入力
するシステムに係わり、特に、すべての作業工程の担当
者が単一の掲示板型データベースを共有する業務処理シ
ステム及びその方法に関する。

【０００２】

【従来の技術】一般に、業務処理は、複数の作業工程の
シーケンスから構成される業務処理プロセスを経て遂行
されることが多い。ある作業工程から次の作業工程に
は、伝票、帳票等を通じて次々にデータが受け渡され、
一連の業務プロセスが遂行される。電子計算機を利用す
るワークフローシステムでは、伝票や帳票を単位とする
情報は電子計算機の記憶装置に格納され、ネットワーク
を介するデータ伝送によって次に作業を行う担当者に渡
される。

【０００３】図２５は、販売業務における業務プロセス
の流れの一例を示す図である。図２５に示される業務プ
ロセスでは、顧客への販売活動を行って引合の後に具体
的に商品の仕様、価格、納期等の見積りが行われる。そ
して、契約が成立したら関連部署に資材調達、製品の設
計や製造、在庫の引当、商品の搬入措置などの手配が行
われる。さらに、商品を客先に納品し、検収を終えた後
に代金の請求／回収が行われる。引合、見積など各段階
は作業工程に相当する。従来技術によれば、ある作業工
程から次の作業工程へのデータの受け渡しは、伝票を単
位として行われる。このため、次の作業工程の担当者へ
の情報の伝達は、伝票上のすべてのデータが揃った時点
で行われる。したがって、次作業工程以降の担当者は、
伝票上のデータがすべて確定するまでその内容を知るこ
とができない。例えば、図２５に示す例において、引
合、見積の段階で商品内容が確定しなくても納品管理の
担当者が商品についてのデータを未確定情報として早く
知りたいような場合、従来の方法では次作業工程以降の
担当者は、その情報を知ることができない。また、業務
処理の結果として電子計算機に入力されるデータのデー
タ項目についても、業務処理の流れに従って確定してい
くとは限らないし、どのデータ項目からデータが確定し
ていくかは必ずしも一意に決められない。例えば、図２
５における見積の段階で商品仕様の商談が先に進めば、
これに関するデータ項目が先に確定する。逆に納期の商
談が先に進めばこれに関するデータ項目が先に確定す
る。しかし、従来の方法によれば、データ項目が確定し
たときに関連部署の担当者に通知しようとすると、その
作業工程の作業担当者がその都度関連部署の担当者の宛
先とデータを指定して送信処理を行わねばならず、担当
者の負担が大きくなるという問題がある。さらに、従来
の方法によれば、一連の業務プロセスを通じて何種類も
の伝票を作成するとともに同じデータを異なる伝票に何
度も入力するいわゆる重複入力をするため、入力ミスを
引き起こす可能性が大きくなるとともに、余計なデータ
入力時間をかけることになる。

【０００４】

【発明が解決しようとする課題】上述したように、従来
技術によれば、ある作業工程から次の作業工程へのデー
タの伝達は、基本的に伝票を単位として行われるため、
伝票上のすべてのデータが揃わないと次の作業工程にデ
ータの伝達が行われなかった。したがって、後工程の作
業者が先行して作業を進めようとしても作業を行えず、
作業効率が上がらないという問題があった。そして、こ
のような業務処理の直列的な流れに反して確定または未
確定のデータを後工程の作業者に伝達しようとすると、
作業者に負担を強いることになるという問題があった。
また、伝票へのデータの重複入力による入力ミスや作業
効率の問題があった。

【０００５】本発明の目的は、上記問題点を解決し、業
務処理システムにおいて、任意の担当者が任意の時点で
必要とするデータを参照することを可能とすることにあ
る。

【０００６】本発明の他の目的は、ある作業工程から次
の作業工程に遷移するときのデータの送受信を極力少な
くし、これに伴う担当者の負担を軽減するとともにネッ
トワークの負荷を軽減することにある。

【０００７】本発明のさらに他の目的は、後工程の担当
者が先行してデータを参照することを可能にするに止ま
らず、後工程の担当者が先行してデータを入力する操作
を許可して作業効率を向上させるとともに、そのときに
生じ易い混乱を防止できるようにすることにある。

【０００８】

【課題を解決するための手段】本発明による業務処理シ
ステムは、一連の業務プロセスに関連するすべてのデー
タ項目の内容をデータベースに集約し、関連するすべて
の担当者がこのデータベースを共有できるようにするこ
とを特徴とする。このとき、作業工程のシーケンスに従
って現在作業中の工程という概念を保存して、現在工程
の担当者が主としてデータ入力やデータ更新をするよう
にし、後工程の担当者が主としてデータ参照できるよう
にする。また、各作業工程について、データ項目ごと
に、作業工程が遷移するために満足すべきデータの状態
を状態遷移ルールとして定義しておく。この状態遷移に
基づいて、作業工程に遷移が生じたか否か判断し、作業
工程が遷移したと判断されたとき、新たに作業を行うこ
とが可能となった作業工程の担当者に作業工程が遷移し
た旨の通知をする。

【０００９】好ましい態様において、本発明の業務処理
システムは、データベースに、現在の作業工程を表す識
別子を設け、作業工程に遷移が生じたときは、新たに作
業を行うことが可能となった作業工程を表す識別子に更
新して、次の作業工程に遷移させる。

【００１０】より好ましい態様において、本発明による
業務処理システムでは、処理期限のある作業工程の各々
について、データ入力を完了すべき期限を設定し、現在
の作業工程がこの期限より前のあらかじめ定めた期日に
来たとき、その担当者に期限が迫っている旨の通知をす
る。さらに、後工程の担当者からのデータの先行入力を
許し、先行入力されたデータ項目に対応してフラグを立
てる。前工程の担当者からのデータ入力の要求があった
とき、フラグが立っている未確定のデータ項目を検出し
て後工程の担当者へ前工程によるデータ変更があった旨
の通知をする。これにより、後工程の担当者が入力した
データを見直しできるようにする。

【００１１】また、本発明による業務処理方法は、デー
タベースの一部のデータ項目に対応して、複数の作業工
程の担当者がそれぞれそのデータ項目のデータについて
意思決定したか否かを示す情報を保持する。複数の作業
工程の担当者がすべて意思決定したときワークフロー上
のデータが確定したものとみなすとともに、担当者にデ
ータの確定を通知することを特徴とする。

【００１２】さらに本発明による業務処理方法は、デー
タベースのデータ項目に対応して、確度が未確定なデー
タ項目のデータを先行して引き取っているか否かを示す
情報を保持する。未確定なデータを先行して引き取って
いる場合には、担当者にその旨通知するようにしたこと
を特徴とする。

【００１３】

【発明の実施の形態】

（１）第１の実施の形態 図１は、本発明による第１の実施の形態の業務処理シス
テムの構成図である。本実施の形態における業務処理シ
ステムは、業務上のデータを格納するデータベースと関
連するファイル、このデータベースを監視するサーバ１
及びネットワーク７０を介してサーバ１に接続され、デ
ータベースへのデータ入力と更新を行う複数のクライア
ント２から構成される。クライアント２は業務処理を遂
行する各部署に配置される端末装置である。掲示板デー
タベース１１は、業務処理に関する最新のデータを格納
し、クライアント２に対して掲示板として機能するデー
タベースである。状態遷移ルール１２は、掲示板データ
ベース１１上のデータ項目のデータ入力状況と入力され
たデータの確度とから、業務処理の流れの中でどの作業
工程の処理を完了させるかを定義するファイルである。
状態遷移期限ルール１３は、各作業工程について処理を
完了すべき期限を定義するファイルである。メッセージ
ファイル１４は、関連部署へ通知するためのメッセージ
を格納するファイルである。宛先ファイル１５は、メッ
セージを送付する宛先を登録するファイルである。掲示
板データベース１１、状態遷移ルール１２、状態遷移期
限ルール１３、メッセージファイル１４及び宛先ファイ
ル１５は、サーバ１に接続される記憶装置上に格納され
る。これらのデータベースやファイルへのアクセスの管
理は、ファイル管理部１６によって行われる。

【００１４】サーバ１の状態監視部３は、掲示板データ
ベース１１と状態遷移ルール１２を参照してステータス
を次の工程に遷移すべきか否かを判定し、遷移するとき
にはメッセージファイル１４及び宛先ファイル１５を参
照して関連部署にメッセージを送信する。また状態監視
部３は、状態遷移期限ルール１３を参照して現在の工程
について処理期限が迫っているか否かを判定し、期限が
迫っているときにはメッセージファイル１４及び宛先フ
ァイル１５を参照して関連部署に警告のメッセージを送
信する。さらに状態監視部３は、現在の工程より後の工
程の業務担当者がデータの先行入力をしたか否かを監視
し、先行入力したデータ項目にフラグを立て、それ以後
に現在工程の担当者がデータを変更したとき、メッセー
ジファイル１４及び宛先ファイル１５を参照して後工程
の担当者へ注意のためのメッセージを送信する。通信制
御部１７は、ネットワーク７０を介してクライアント２
との間に行われるデータやメッセージの送受信を制御す
る制御部である。

【００１５】クライアント２の表示装置２１は、掲示板
やメッセージを表示する装置であり、具体的にはＣＲＴ
ディスプレイなどが用いられる。入力装置２２は、掲示
板上にデータを入力する装置であり、例えば、キーボー
ド、マウスなどが用いられる。ユーザ入出力部２３は、
ユーザインタフェースを実現する処理部であり、あらか
じめ画面設計された表示画面の様式に従ってサーバ１か
ら受け取ったデータを表示装置２１上に表示し、入力装
置２２から入力されたデータを、サーバ１へ送信する。
通信制御部２４は、ネットワーク７０を介してサーバ１
との間で行われるデータやメッセージの送受信を制御す
る制御部である。サーバ１及びクライアント２は、パソ
コン、ワークステーションを含む情報処理装置によって
構成される。状態監視部３、ファイル管理部１６、通信
制御部１７、ユーザ入出力部２３及び通信制御部２４
は、この情報処理装置のハードウェアによって又はその
記憶装置に格納されるプログラムを実行することによっ
て実現される。なお、掲示板データベース１１を始めと
するデータベースやファイル及びファイル管理部１６を
ネットワークを介してサーバ１と接続される別のサーバ
によって実現してもよい。

【００１６】図２は、掲示板データベース１１のデータ
形式の例を示す図である。掲示板データベース１１は、
少なくとも１組の掲示板データを保持している。各掲示
板データは、項番１１０、掲示板番号１１１、ステータ
ス１１２、複数のデータ項目１１３、及び各データ項目
に対応してそのデータ項目に登録されたデータの状態を
示す属性情報を含む。項番１１０は、テーブル内でのレ
コードの番号を表す。掲示板番号１１１は、掲示板デー
タベース１１に格納されている個々の掲示板を区別する
ために付される識別子となる番号である。ステータス１
１２は、業務プロセスの流れを通じて作業工程のシーケ
ンスの順番に各工程の名称を設定する工程の識別子であ
る。データ項目１１３は、業務処理の結果としてデータ
が入力される項目である。データ項目とは、例えば、一
般的な事務処理で利用される伝票上の項目に相当するも
ので、データ項目１１３に設定されるデータは、伝票に
記入されるデータに相当する。本実施の形態では、デー
タ項目の具体例として「顧客名」、「商品名」、「受注
数」、「納期」、「価格」、及び「納入場所」を例示し
ている。各データ項目１１３には、そこに与えられるデ
ータの状態を表す属性情報が付与されている。属性情報
には、対応するデータ項目に入力されたデータが確定し
たものであるか未確定なものであるかを示す確度１１４
と、後工程が先行してデータを入力したときに１が設定
されるフラグ１１５が設けられる。本実施の形態では、
確度１１４に「確定」が設定されたデータ項目の更新
は、原則として禁止される。なお、掲示板データは、業
務処理システムで行われる業務について、いわゆる掲示
板のように、各クライアント２０から少なくともその一
部を参照することが可能な情報である。業務処理システ
ム上で処理される個々の一連の業務に対応して掲示板デ
ータは形成される。

【００１７】図３は、状態遷移ルール１２のデータ形式
の例を示す図である。状態遷移ルール１２は、データ項
目のデータ入力状況と入力されたデータの確度とからど
の作業工程の処理を完了させるかを定義するとともに、
データ入力の履歴をも示している。図から理解されるよ
うに、掲示板データベース１１とほぼ同様の形式を有す
る。掲示板データベース１１は、現在の工程についての
最新データのみを保持しているのに対し、状態遷移ルー
ル１２は各作業工程ごとにレコードを有し、それぞれの
作業工程において入力、更新されたデータを保持する。
掲示板データベース１１の内容と状態遷移ルール１２の
対応する作業工程の内容とは一致している。各作業工程
においてデータ入力が必要とされないデータ項目には、
初期状態において“未定”が設定される。状態遷移ルー
ル１２は、初期状態ではステータス１２１と、“未定”
が設定されたデータ項目以外の欄はスペースである。例
えば「引合」の工程では、初期状態において、データ項
目１２２の中で「納期」、「価格」、「納入場所」に
は、“未定”が設定されており、「顧客名」、「商品
名」、「受注数」のデータ項目はスペースである。した
がって、「顧客名」、「商品名」、「受注数」のデータ
項目にデータ入力されるとスペースであったデータ項目
がなくなるので、「引合」工程は完了となる。同様に
「見積」工程では「納入場所」以外のすべてのデータ項
目にデータ入力されるとスペースのデータ項目がなくな
るので、「見積」工程は完了となる。本実施の形態で
は、データ項目の確度１２３がすべて確定でなければ次
の工程に遷移できない。

【００１８】図４は、状態遷移期限ルール１３のデータ
形式の例を示す図である。ステータス１３１は、ステー
タス１１１と同じく業務フローを構成する工程を順に並
べたものである。顧客名、形名及び納期は、業務に関す
るデータ項目である。処理期限１３２は、当該工程につ
いて処理を完了させねばならない締め切り日である。警
告日１３３は、処理期限が迫っているとき処理期限１３
２の何日前に警告メッセージを発行するかを示す。項番
と掲示板番号は、掲示板データベース１１と同じであ
る。初期状態ではステータス１３１の各工程名と警告日
１３３だけが設定されている。業務に関するデータ項目
は、掲示板データベース１１の更新に応じてその内容が
反映される。処理期限１３２は、管理者によって設定さ
れる。

【００１９】図５は、メッセージファイル１４のデータ
形式の例を示す図である。ステータス１４１は、ステー
タス１１１と同じく業務フローを構成する工程を順に並
べたものである。メッセージ１４２には、各工程につい
て工程が遷移したとき、処理期限が迫ったとき及び前工
程によつてデータ変更があったときに発行するメッセー
ジが設定される。

【００２０】図６は、宛先ファイル１５のデータ形式の
例を示す図である。ステータス１５１は、ステータス１
１１と同じく業務フローを構成する工程を順に並べたも
のである。宛先ファイル１５には、各工程対応に宛先情
報としてメッセージを送付するときの宛先部署と担当者
名が設定される。また宛先情報には、電子メールのアド
レスを設定するようにしてもよい。

【００２１】図７は、クライアント２の表示装置２１に
表示される掲示板のデータ形式の例を示す図である。掲
示板には、掲示板データベース１１の各データ項目の値
が表示される。図７（ａ）は、納入場所以外のデータ項
目についてデータ入力が済んでいる状態であり、ステー
タスが「見積中」であることを示している。また図７
（ｂ）は、すべてのデータ項目についてデータ入力が済
んでいる状態であり、ステータスが「受注」完了である
ことを示している。各データ項目の属性、すなわち確度
の確定／未確定の区別及びフラグの有無は、そのデータ
項目の表示色、ブリンク表示の有無等によって区別する
ことができる。

【００２２】図８は、状態監視部３の処理の流れを示す
フローチャートである。クライアント２のユーザ入出力
部２３から通信制御部２４及び通信制御部１７を介して
掲示板番号、工程名、顧客名などを指定して掲示板の要
求を受信したとき（ステップ３１）、状態監視部３は掲
示板データベース１１を検索して、掲示板番号で指定さ
れた掲示板の情報を取り出す（ステップ３２）。そし
て、状態監視部３は、取り出した掲示板の情報を通信制
御部１７を介してクライアント２へ送信する（ステップ
３３）。クライアント２のユーザ入出力部２３はこの掲
示板をオープンし、表示装置２１上に表示する。

【００２３】クライアント２側で入力装置２２を介して
データ項目又は確度についてデータの入力又は更新があ
ったとき、ユーザ入出力部２３は、通信制御部２４を介
してサーバ１へこの入力／更新データを送信する。入力
／更新データはサーバ１により受信され、状態監視部３
に渡される（ステップ３４）。状態監視部３は、入力／
更新データを受け取ると、状態遷移期限ルール１３を参
照して、掲示板番号が一致しステータス１３１が現在の
工程名に一致するエントリの処理期限１３２と現在日付
とを比較する。この比較結果に基づいて、状態監視部３
は、処理期限が過ぎているか否かを判定する（ステップ
３５）。現在日付が処理期限を過ぎている場合は、デー
タ入力元のクライアント２へデータ入力不可である旨の
メッセージを送信し、処理を終了する（ステップ４
５）。なおステップ３５では、現在の工程より前の工程
についてクライアント２からデータ入力要求があった場
合も処理期限が過ぎているものとみなしてステップ４５
の処理に移る。処理期限が過ぎてからのデータ入力要求
や状態遷移後の前工程についてのデータ更新は、特別の
許可を得た場合を除いて禁止される。なお、現在の工程
が処理期限１３２を過ぎていることを検出したとき、管
理者等へメッセージを送信し、その旨通知するようにし
てもよい。

【００２４】一方、ステップ３５の判定の結果、現在日
付が処理期限を過ぎていないことが確認されると、状態
監視部３は、入力されたデータによって掲示板データベ
ース１１を更新する（ステップ３６）。次に状態監視部
３は、状態遷移ルール１２を参照して、掲示板番号が一
致し、ステータス１２１が現在の工程名に一致するエン
トリのデータを最新データによって更新する（ステップ
３７）。そして、後述する、後工程からのデータの先行
入力の確認処理を行う（ステップ３８）。この後、状態
監視部３は、状態遷移ルール１２を参照して状態遷移が
生じたか否かを判定する。ここでは、状態監視部３は、
ステータス１２１が現在の工程名に一致するエントリに
ついて、“未定”が設定されたデータ項目を除くすべて
のデータ項目にデータが入力され、その確度１２２がす
べて「確定」であるとき、次の工程への遷移が生じたと
判定する（ステップ３９）。

【００２５】ステップ３９において状態遷移があると判
定されたとき、状態監視部３は状態遷移期限ルール１３
中の掲示板番号が一致し、ステータス１３１が現在の工
程名に一致するエントリの内容を最新データによって更
新する。また、掲示板データベース１１のステータス１
１２を次の工程名に更新する（ステップ４０）。次の工
程名は状態遷移ルール１２において、現工程の次のレコ
ードのステータス１２１に登録されている。続いて、メ
ッセージファイル１４及び宛先ファイル１５を参照し
て、次の工程の関連部署へ、前の工程のデータ入力が完
了した旨のメッセージを送信し、処理を終了する（ステ
ップ４１）。ここで送信されるメッセージは、メッセー
ジファイル１４の掲示板番号が一致し、ステータス１４
１が次の工程名であるエントリの該当するメッセージで
ある。またメッセージの宛先は、宛先ファイル１５のス
テータス１５１が次の工程名であるエントリの宛先部
署、担当者名等である。なお状態監視部３はメッセージ
とともに掲示板番号、データ入力が済んだデータ項目の
名称とデータなど掲示板データベース１１から必要なデ
ータを抽出してこの関連部署へ送信する。メッセージを
受けた関連部署は、クライアント２及びサーバ１を介し
て掲示板をオープンすることができる。

【００２６】ステップ３９において状態の遷移がないと
判断されると、状態監視部３は状態遷移期限ルール１３
を参照して、掲示板番号が一致し、ステータス１３１が
現在の工程名に一致するエントリのデータを最新データ
によって更新する（ステップ４２）。次に、当該エント
リの処理期限１３２及び警告日１３３を参照して現在日
付が警告日１３３に設定する警告日に達しているか否か
を判定する（ステップ４３）。期限が迫っていなけれ
ば、処理を終了する。期限が迫っていれば、メッセージ
ファイル１４及び宛先ファイル１５を参照し、現在工程
の関連部署へ期日が迫っている旨のメッセージを送信し
た後、処理を終了する（ステップ４４）。ここで送信す
るメッセージは、メッセージファイル１４の掲示板番号
が一致し、ステータス１４１が現在の工程名であるエン
トリの該当するメッセージである。メッセージの宛先
は、宛先ファイル１５のステータス１５１が現在の工程
名であるエントリの宛先部署、担当者名等に基づき決定
される。状態監視部３は、メッセージとともに掲示板番
号、データ入力が済んだデータ項目の名称とデータ、デ
ータ未入力のデータ項目の名称など掲示板データベース
１１から必要なデータを抽出してこの関連部署へ送信す
る。

【００２７】図９は、ステップ３８で行われる後工程か
らのデータの先行入力の確認処理の流れを示すフローチ
ャートである。ステップ３７から制御が移ったとき、状
態監視部３は、後工程によるデータ入力か否かを判定す
る（ステップ６１）。後工程によるデータ入力か否か
は、データ入力要求のあった工程名と掲示板データベー
ス１１のステータス１１２にある現在の工程名とを比較
することによって判定する。現在工程より後の工程の名
称は、状態遷移ルール１２のステータス１２１に登録さ
れており、確認可能である。後工程によるデータ入力で
あれば、掲示板データベース１１及び状態遷移ルール１
２の先行入力されたデータ項目に対応するフラグ１１
５、１２３をオンにして、ステップ３９の処理に移る
（ステップ６２）。一方、ステップ６１で後工程による
データ入力でないと判定されると、次に、先行して入力
されているデータ項目があるか否かを判定する。掲示板
データベース１１において現在工程のデータ項目の中で
フラグ１１５がオンとなっているデータ項目があれば、
そのデータ項目が先行入力されたデータ項目である（ス
テップ６４）。先行入力のデータ項目がなければ、その
ままステップ３９へ行く。ステップ６４で先行入力のデ
ータ項目があれば、そのデータ項目の確度の判定を行う
（ステップ６５）。先行入力されたデータ項目に対応す
る確度１１４がすべて“確定”となっていれば、ステッ
プ３９へ行く。先行入力されたデータ項目のいずれかの
確度１１４が“未確定”ならば、続いて、前工程による
データ変更があったか否かを判定する。データ入力要求
のあった工程が現在の工程であって、業務に関するいず
れかのデータ項目についてデータ入力又はデータ更新が
あったとき、前工程によるデータ変更に該当する（ステ
ップ６６）。前工程によるデータ変更があったときは、
メッセージファイル１４及び宛先ファイル１５を参照し
て、前工程からデータ変更があった旨のメッセージを関
連部署へ送信する。送信するメッセージは、メッセージ
ファイル１４の掲示板番号が一致し、ステータス１４１
が現在の工程名より後にあるエントリの該当するメッセ
ージである。またメッセージの宛先は、宛先ファイル１
５のステータス１５１が現在の工程名より後にあるエン
トリの宛先部署、担当者名等である。なお状態監視部３
はメッセージとともに掲示板番号、前工程によるデータ
入力／更新のあったデータ項目の名称とデータなどを関
連部署へ送信する（ステップ６７）。最後に掲示板デー
タベース１１及び状態遷移ルール１２のフラグ１１５、
１２３をすべてオフにして、ステップ３９へ行く（ステ
ップ６９）。ステップ６５において前工程によるデータ
変更がないと判定されたときは、そのままステップ３９
に移る。

【００２８】上記実施の形態によれば、掲示板データベ
ース１１のステータスに格納される現在の工程より後の
工程の業務担当者は先行してデータ入力や更新が可能で
ある。しかし、現在工程がある特定の工程に到達したと
き、その工程の処理が完了しない限り後工程が掲示板を
参照するか又は先行入力する操作を許可しないように制
約を設けてもよい。

【００２９】また、上記実施形態によれば、現在の工程
について設定された処理期限１３２に到達しなくとも、
その工程に必要なデータ項目のデータ入力が終了し、入
力されたデータの確度１１５が“確定”であれば自動的
に次の工程に遷移するので、動的にワークフローを形成
することができる。しかも状態遷移ルール１２に過去の
データ入力及び更新の履歴を残すので、必要に応じて過
去のデータ入力／更新の状況をたどることができる。た
だ、これだけでは、掲示板を見ない担当者がいるとワー
クフローの流れが停滞してしまう。そこで、本実施の形
態では処理期限が迫ったとき、関連部署の担当者に警告
メッセージを送ることによって遅れているデータ入力を
促進することを可能としている。また現在の工程という
概念を保存しながら後工程の作業者がデータ入力できる
データ項目については先行入力できるようにして作業効
率を上げるようにした。ただし前工程（現在工程）が後
からデータ変更することによって後工程が行ったデータ
入力、特に未確定のデータ入力を見直す必要がある場合
がある。本実施の形態では、前工程がデータ変更したと
き後工程が未確定のデータを先行入力している場合にメ
ッセージを送信するので、後工程がデータの先行入力を
しても混乱が生じることはない。

【００３０】（２）第２の実施の形態 第１の実施の形態によれば、１人の担当者がクライアン
ト２を介して掲示板データベース１１の各データ項目に
ついて「確定」する旨入力すればそのデータ項目に対応
する確度１２２が「確定」に設定され、データが確定し
た。１人の担当者の意思決定によってデータを確定して
よいデータ項目についてはこの方法で充分である。しか
し、データ項目によっては２つ以上の関連する部門の担
当者がともに意思決定したり、担当者の意思決定の後に
管理者の決裁を得て初めて、すなわち何らかの合議の結
果としてデータを確定すべきデータ項目も存在する。第
２の実施の形態ではこのような合議を必要とするデータ
項目については、関連する部門のユーザがともに意思決
定して初めて確定データとみなすとともに、ユーザの状
況把握のために合議の状況を常時ユーザに通知可能とす
る。また、第１の実施の形態では、あるデータ項目につ
いて、後工程のユーザが先行入力したことは前工程のユ
ーザに通知されるが、「未確定」のデータが他のユーザ
によって参照され作業のための基礎データとなったか否
かを知る手段はない。第２の実施の形態では「未確定」
のデータに基づいて他のユーザが作業を進めている、す
なわち他のユーザが「未確定」データを引き取っている
ことをデータ入力したユーザが知り得るようにし、ユー
ザがこのような先行引取に伴う状況把握をできるように
した。

【００３１】図１０は、本発明の第２の実施の形態にお
ける業務処理システムの構成図である。図１０におい
て、図１と同一の参照番号が付されているものは、図１
の対応する部分と同様の機能、構成を有する。掲示板デ
ータベース１８は、第１の実施の形態の掲示板データベ
ースと同様に、クライアント２に対して掲示板として機
能するデータベースであるが、そのデータ形式は、第１
の実施の形態とは異なっている。状態遷移ルール２０も
第１の実施の形態と機能的には同一であるが形式が異な
る。状態遷移ルール２０が第１の実施の形態の状態遷移
ルール１２と相違する点は、後述する掲示板データベー
ス１８と第１の実施の形態の掲示板データベース１１の
相違と共通するものであり、ここでは詳細な説明は省略
する。アクセス権限ファイル１９は、掲示板データベー
ス１８の各データ項目のデータ及び各種フラグについ
て、各作業工程のユーザごとに参照又は書き込みの可否
を設定するファイルである。アクセス権限ファイル１９
は、他のファイル類と同様に、サーバ１に接続される記
憶装置上に格納される。サーバ１の状態監視部４は、第
１の実施の形態における状態監視部３の機能の他、各デ
ータ項目のデータの決定状況の判定、データの確度の判
定、データの先行引取の判定、及び関連するフラグの設
定を行う機能を有する。クライアント２は、第１の実施
形態のクライアント２と同様の機能を含んで構成され
る。サーバ１とクライアント２との間に送受信されるデ
ータの形式が第１の実施の形態と異なるので、ユーザ入
出力部２３の処理が第１の実施の形態とは多少異なる
が、主たる機能としては大きく異なるものではないの
で、ここでは、第１の実施の形態と同一の参照番号を用
いている。なお、以下の説明において、具体的な例を挙
げて説明を行っている部分では、ユーザである営業担当
者、営業課長及び倉庫担当者により図２５に例示した業
務が行われることを想定している。

【００３２】図１１は、掲示板データベース１８のデー
タ形式を示す図である。なお、以下の説明ではデータ項
目として「顧客名」、「商品名」、「数量」、「納入
価」及び「納期」がある場合を考える。本実施の形態の
掲示板データベース１８は、各データ項目に対応して設
定される属性情報が第１の実施の形態とは異なってい
る。本実施の形態では、データ項目に設定されたデータ
の状態を表す属性情報として、合議フラグ１８１、決定
フラグ１８２、引取フラグ１８３、合議依頼元決定フラ
グ１８４、合議回答元決定フラグ１８５、合議実施フラ
グ１８６、合議依頼元引取フラグ１８７、合議回答元引
取フラグ１８８及び他部門引取フラグ１８９が設けられ
る。合議フラグ１８１は、全てのデータ項目に対応して
設けられ、対応するデータ項目の内容について、そのデ
ータ項目に設定されたデータを確定するために複数の処
理者による合議が必要であるか否かを示すフラグであ
る。合議フラグ１８１が“０”であれば合議の必要がな
く、“１”であれば合議を必要とする。合議フラグ１８
１に“０”が設定されているデータ項目については、属
性情報として、決定フラグ１８２、引取フラグ１８３が
含まれる。決定フラグ１８２は、第１の実施の形態にお
ける確度１２２に相当するフラグであり、入力者が対応
するデータ項目の内容について意思決定したか否かを表
すフラグである。この場合は、決定フラグの状態が
“１”になると、そのデータ項目に設定されているデー
タが確定データであることを意味する。引取フラグ１８
３は、合議が必要ないデータ項目の未確定状態のデータ
について、他部門が先行してデータを引き取っているこ
とを表すフラグである。他部門により対応するデータ項
目にデータが引き取られているとき、引取フラグ１８３
に“１”が設定される。例えば、図１１において、デー
タ項目「顧客名」に着目すると、合議フラグ１８１には
“０”が設定されており、このデータ項目については合
議が不要であることがわかる。そして、決定フラグ１８
２には“１”が設定されており、このデータ項目に設定
されているデータ“Ａ社”は確定していることが示され
ている。また、引取フラグ１８３にも“１”が設定され
ており、現在、他部門にデータが引き取られていること
がわかる。

【００３３】一方、合議フラグ１８１が“１”である場
合には、依頼元決定フラグ１８４、回答元決定フラグ１
８５、合議実施フラグ１８６、依頼元引取フラグ１８
７、回答元引取フラグ１８８及び他部門引取フラグ１８
９が属性情報に含まれる。依頼元決定フラグ１８４は、
合議を依頼する処理者の意思決定の状態を表す。回答元
決定フラグ１８５は、合議の依頼に対し回答する処理者
の意思決定の状態を表す。各データ項目に入力されたデ
ータが確定データであるか未確定データであるかは、こ
れら二つのフラグによって判別される。依頼元決定フラ
グ１８４と回答元決定フラグ１８５が共に“１”になっ
たときにそのデータ項目のデータは確定状態となり、そ
れ以外では未確定状態である。なお依頼元により決定さ
れたデータを回答元が書き換えた場合、あるいは回答元
により決定されたデータを依頼元が書き換えた場合は、
それぞれ合議依頼元決定フラグ１８４あるいは合議回答
元決定フラグ１８５が“０”に置き換わる。合議実施フ
ラグ１８６は、合議が実施された場合に“１”にセット
される。合議依頼者が意思決定を行って合議依頼したデ
ータに対し、合議回答元が値を訂正して意思決定を行っ
た場合は、依頼元と回答元の間で合議が成立しておら
ず、データは確定しないが、合議は実施されたとみなし
て合議実施フラグ１８６が“１”にセットされる。依頼
元引取フラグ１８７、回答元引取フラグ１８８、他部門
引取フラグ１８９は、データ項目に設定されているデー
タが未確定である場合に、そのデータがそれぞれ合議依
頼元、合議回答元、他部門に引き取られるときに“１”
が設定される。本実施の形態においては、合議が必要と
されるデータを、合議に加わらない他部門が引き取ろう
とする場合には、合議実施フラグ１８６が“１”となっ
ていることが必要であるものとする。図１１において、
例えば、データ項目「納入価」に着目すると、合議フラ
グ１８１には“１”が設定されており、このデータ項目
について合議が必要とされることが示されている。デー
タの確定状態は、依頼元決定フラグ１８４は“１”であ
るが、回答元決定フラグ１８５は“０”であるので、合
議依頼元による意思決定はされているが、合議回答元に
よる意思決定がされておらず、未確定状態である。ま
た、合議実施フラグ１８６は、“０”であるので、未だ
合議は行われておらず、他部門でこのデータを引き取る
ことはできないことがわかる。

【００３４】その他、属性情報として、各データ項目に
対応して第１の実施の形態と同様に、先行入力フラグ１
１５が設けられる。なお、掲示板データベース１８の構
造として、各データ項目のデータと対応するフラグとを
記憶装置上では分離して格納し、各データ項目のデータ
から対応するフラグへアドレスポインタによってリンク
するようなデータ構造としてもよい。

【００３５】図１２は、アクセス権限ファイル１９のデ
ータ形式の例を示す図である。アクセス権限ファイル１
９は、ユーザ別にアクセス可能なデータとそのフラグに
ついての権限を定義するファイルである。図１２では、
図１１に示すデータ項目の内、「納入価」、「納期」及
びこれらデータ項目に対応する各属性情報についての定
義は、図示を省略している。図中、参照のフィールドに
“−”が設定されているデータ又はフラグは、参照が禁
止されることを表す。書き込みのフィールドに“−”が
設定されているデータ又はフラグは、書き込み又は更新
ができないことを示している。書き込みのフィールドに
設定される“可”は書き込み又は更新が許可されること
を示し、参照のフィールドの“可”はデータを参照する
ことが許可されることを示している。例えば、データ項
目「商品名」について見ると、商品名というデータその
ものについて営業担当者は参照・書き込み共に可能であ
る。営業課長及び倉庫担当者は、データ項目「商品名」
のデータを参照することはできるが、書き込みはできな
い。決定フラグ１８２については、営業担当者は参照・
書き込みを許可されるが、営業課長及び倉庫担当者は参
照のみが許可され、書き込みは許可されない。これは商
品名が合議の必要ないデータ項目であり、営業担当者の
裁量で決定されたデータが確定となるためである。つま
り営業課長及び倉庫担当者は決定されたか否か、すなわ
ち確定されたか否かを決定フラグ１８２で確認すること
はあっても、データの決定の操作は行えないことを示し
ている。次に引取フラグ１８３については、営業担当者
は書き込みできないが参照は可能である。一方、営業課
長及び倉庫担当者は、引き取りフラグに対して書き込み
はできるが参照はできない。これは商品名というデータ
項目について営業課長及び倉庫担当者は営業担当者の決
定の如何にかかわらずデータを引き取ることができるこ
とを示している。営業課長及び倉庫担当者が先行してデ
ータを引き取ったことを示す表示は、営業担当者側の表
示装置２１に表示される。営業担当者は引き取られる側
なのでデータを「引き取った」ことを示す引取フラグ１
８３への書き込みはできない。しかし表示画面上には、
データが「引き取られた」ことが表示されるため、参照
は「可」となる。一方、営業課長及び倉庫担当者は、デ
ータの引き取りを行える部署である。したがって、引取
フラグ１８３への書き込みは“可”に設定される。営業
課長及び倉庫担当者に対しては引き取ったことを示す表
示は不要であり、参照フィールドには“−”が設定され
ている。また、本実施の形態では、依頼元決定フラグ１
８４の書き込みができるユーザが合議依頼元であり、回
答元決定フラグ１８５の書き込みができるユーザが合議
回答元である。例えば「数量」というデータ項目につい
ては、営業担当者が合議依頼元、倉庫担当者が合議回答
元である。なおステータス１２１及び先行入力フラグ１
２３は、いずれのユーザからも参照可能であるが、書き
込みはできない。また、合議フラグ１８１は、状態監視
部４のプログラムが処理上必要な情報であり、ユーザが
直接書き込み又は参照することがないため全てのフィー
ルドに“−”が設定されている。

【００３６】図１３は、サーバ１とクライアント２の間
で送受信されるデータの形式を示すフォーマット図であ
る。図１３（ａ）は、サーバ１からクライアント２に送
信される掲示板データの形式を示している。各データ項
目のデータには、決定フラグ１６１、確度フラグ１６２
及び先行引取フラグ１６３が付加される。決定フラグ１
６１は対応するデータ項目の決定フラグの状況を示すフ
ラグであり、合議の必要ないデータ項目については決定
フラグ１８２の値が格納される。合議を必要とするデー
タ項目については、送信先ユーザが合議依頼元か合議回
答元かによってそれぞれ依頼元決定フラグ１８４又は回
答元決定フラグ１８５の値が格納される。確度フラグ１
６２は対応するデータ項目が確定しているか否かを示す
フラグである。先行引取フラグ１６３は、対応するデー
タ項目が先行引取されたか否かを示すフラグである。

【００３７】図１３（ｂ）は、クライアント２からサー
バ１へ送信されるデータの形式を示している。送信され
るデータは、各データ項目ごとにサーバ１から送られた
か又はクライアント２で入力・更新されたデータとそれ
に付属する決定フラグ１６１及び引取フラグ１６４から
構成される。決定フラグ１６１は、サーバから送られる
データ中の決定フラグと同じ意味を有する。クライアン
ト２からサーバ１に送られるデータ中の決定フラグ１６
１には、対応するデータ項目に対するユーザの決定の意
思が反映される。例えば、あるデータ項目に関して、サ
ーバから決定フラグ１６１に“０”が設定されて送られ
てきた未決定のデータに対して、ユーザによりそのデー
タを決定するための操作が行われると、決定フラグ１６
１に“１”が設定されてサーバ１に送られる。引取フラ
グ１６４は、ユーザが対応するデータを引き取ったこと
をサーバ１に通知するために使用される。ユーザは所望
のデータ項目のデータについて引取の操作をすることが
でき、ユーザによりデータの引き取り操作が行われる
と、そのデータ項目に対応する引取フラグ１６４に
“１”が設定される。

【００３８】図１４は、状態監視部４の処理の流れを示
すフローチャートである。本実施の形態における状態監
視部４の処理は、図１４に示すように、図８に示す第１
の実施の形態における処理のステップ３２と３３の間に
ステップ７１から７６の処理が追加され、ステップ３６
の処理がステップ７７、７８の処理と置き換えられる。
ここでは、主に、本実施の形態において新たに行われる
処理について以下に説明し、第１の実施の形態と重複す
る処理についてはその説明を省略する。状態監視部４
は、クライアント２からの要求に応じて掲示板データベ
ースから指定された掲示板を取り出すと（ステップ３１
〜３２）、要求のあったユーザを識別子に基づいて認識
する（ステップ７１）。この認識結果にしたがってアク
セス権限ファイル１９を検索して、当該ユーザの各デー
タ及びフラグについてのアクセス権限情報を取り出す
（ステップ７２）。次に、取り出したアクセス権限情報
に基づいて、ステップ３２で取り出された掲示板の中で
当該ユーザが参照可能なデータ、すなわち表示可能なデ
ータを選択する（ステップ７３）。

【００３９】次に状態監視部４は、選択されたデータ及
びフラグの中から決定フラグによる決定状況の判定を行
い、クライアント２に送信する各データ項目に付加する
決定フラグ１６１の値を求める。例えば、ステップ７３
で選択されたあるデータ項目が合議を必要としないデー
タ項目である場合、決定フラグ１８２が“１”であれ
ば、状態監視部４は送信するデータ項目に付属する決定
フラグ１６１の値を“１”に設定する。一方、決定フラ
グ１８２が“０”であれば決定フラグ１６１の値を
“０”に設定する。また、ステップ７３で選択されたあ
るデータ項目が合議を必要とするデータ項目である場
合、状態監視部４は当該ユーザが合議依頼元であって依
頼元決定フラグ１８４が“１”であれば、決定フラグ１
６１に“１”を設定する。依頼元決定フラグ１８４が
“０”であれば、決定フラグ１６１には“０”が設定さ
れる。同様に、当該ユーザが合議回答元であって回答元
決定フラグ１８５が“１”であれば、状態監視部４は決
定フラグ１６１の値を“１”に設定し、回答元決定フラ
グ１８５が“０”であれば決定フラグ１６１の値を
“０”に設定する。さらに、当該ユーザが合議依頼元で
も合議回答元でもない場合、状態監視部４は、依頼元決
定フラグ１８４及び回答元決定フラグ１８５がともに
“１”であれば決定フラグ１６１に“１”を設定し、そ
れ以外の場合には決定フラグ１６１に“０”を設定す
る。これにより、合議を必要とするデータ項目であって
も合議に関係ないユーザからみれば、このデータ項目は
合議を必要としないデータ項目と同様に見える。状態監
視部４は選択されたすべてのデータ項目について以上の
処理を行う（ステップ７４）。

【００４０】状態監視部４は、選択された各データ項目
に付加される決定フラグの値を決定すると、合議フラグ
１８１及び決定した決定フラグの値に基づいてデータの
確度を判定する。確定されたデータについては送信する
データ項目に付属する確度フラグ１６２を“１”に設定
し、未確定データについてはこの確度フラグ１６２を
“０”に設定する。状態監視部４は選択されたすべての
データ項目についてこの処理を行う。ここでの処理の詳
細については後述する（ステップ７５）。

【００４１】次に状態監視部４は、引取フラグ１８３、
依頼元引取フラグ１８７、回答元引取フラグ１８８及び
他部門引取フラグ１８９を参照してデータが先行引取さ
れているか否かを判定する。先行引取されているデータ
については送信するデータ項目に付属する先行引取フラ
グ１６３を“１”に設定する。状態監視部４は選択され
たすべてのデータ項目についてこの処理を行う。この処
理の詳細については後述する（ステップ７６）。

【００４２】状態監視部４はステップ７３で選択された
データ項目のデータ、及び選択されてデータ項目につい
てステップ７４〜７６で決定した決定フラグ１６１、確
度フラグ１６２及び先行引取フラグ１６３をまとめて送
信データとし、通信制御部１７を介してクライアント２
へ送信する。クライアント２では、サーバ１から送られ
たデータを表示装置２１上に表示し、ユーザによる業務
処理が行われる。クライアント２における業務処理の結
果としてデータ項目、決定フラグ又は引取フラグに対す
る入力又は更新があったとき、入力・更新されたデー
タ、又はフラグは、先に説明した図１３（ｂ）に示すデ
ータフォーマットにまとめられ、サーバ１に送られる。
状態監視部４はこの入力データを受信し、処理期限前か
否かのチェックを行う（ステップ３３〜３５）。

【００４３】処理期限前であることが確認されると、状
態監視部４は、クライアント２から送られてきたデータ
及び決定フラグ１６１にしたがって掲示板データベース
１８を更新する。状態監視部４は、アクセス権限ファイ
ル１９に基づいて当該ユーザによる更新が許可され、か
つデータ入力可能なデータ項目及びフラグを更新する。
ここで、受信したデータ中の決定フラグ１６１に基づく
フラグの更新処理は次の通り行われる。合議フラグ１８
１が“０”であるデータ項目については、受信した決定
フラグ１６１の値を決定フラグ１８２に設定する。すな
わちユーザから意思決定があれば、決定フラグ１８２は
“１”に設定される。合議フラグ１８１が“１”である
データ項目について、ユーザが合議依頼元であり、元の
依頼元決定フラグ１８４が“０”、決定フラグ１６１が
“１”であれば、状態監視部４は依頼元決定フラグ１８
４を“１”に設定する。ユーザが合議回答元であり、元
の回答元決定フラグ１８５が“０”、決定フラグ１６１
が“１”のときも同様に合議回答元決定フラグ１８５を
“１”に設定する。この操作により依頼元決定フラグ１
８４及び回答元決定フラグ１８５の両方が“１”になっ
たときには、合議実施フラグ１８６を“１”に設定す
る。依頼元決定フラグ１８４が“１”であるデータ項目
のデータを回答元が更新したときは、回答元決定フラグ
１８５の内容にかかわらず依頼元決定フラグ１８４を
“０”に変更し、合議実施フラグ１８６に“１”を設定
する。回答元決定フラグ１８５が“１”であるデータ項
目のデータを依頼元が更新したときは、依頼元決定フラ
グ１８４の内容にかかわらず回答元決定フラグ１８５を
“０”に変更し、合議実施フラグ１８６を“１”にする
（ステップ７７）。

【００４４】次に、状態監視部４は、引取フラグを設定
する処理を行う。合議フラグ１８１に“０”が設定され
ており、かつ決定フラグ１８２が“０”であるデータ項
目については、受信した引取フラグ１６４の値が引取フ
ラグ１８３に設定される。すなわち、状態監視部４はユ
ーザから先行引取の要求があれば、引取フラグ１８３に
“１”を設定する。合議フラグ１８１が“１”であるデ
ータ項目に対しては、受信した引取フラグ１６４が
“１”であるとき、ユーザが合議依頼元、合議回答元又
は他部門のいずれかによって、また合議実施フラグ１８
６、依頼元決定フラグ１８４、回答元決定フラグ１８５
の状態にしたがって依頼元引取フラグ１８７、回答元引
取フラグ１８８及び他部門引取フラグ１８９の設定が制
御される（ステップ７８）。

【００４５】以上のようにして掲示板データベース１８
を更新すると、状態監視部４は、第１の実施の形態と同
様にステップ３７〜ステップ４４の処理を行う。

【００４６】図１５は、ステップ７５で行われるデータ
の確度判定処理の詳細なフローチャートである。状態監
視部４はステップ７選択されたデータ及びフラグについ
て、合議フラグ１８１に“１”が設定されているか否か
判定する（ステップ８１）。合議フラグ１８１が“０”
場合、状態監視部４はそのデータ項目について決定フラ
グ１８２の値の判定を行う（ステップ８４）。決定フラ
グ１８２が“１”であれば、クライアント２側へ送信す
るデータ項目に付属する確度フラグ１６２が“１”に設
定される（ステップ８５）。決定フラグ１８２が“０”
である場合は送信するデータ項目に付属する確度フラグ
１６２は“０”に設定される（ステップ８６）。一方、
ステップ８１において合議フラグ１８１が“１”の場
合、状態監視部４は、続いて、依頼元決定フラグ１８４
に基づき、合議依頼元がデータを決定しているか否かを
判定する（ステップ８２）。依頼元決定フラグ１８４が
“０”の場合、状態監視部４は、送信するデータ項目に
付属する確度フラグ１６２を“０”に設定する（ステッ
プ８６）。依頼元決定フラグ１８４が“１”の場合、状
態監視部４はさらに、回答元決定フラグに基づき合議回
答元がデータを決定しているか否かを判定する（ステッ
プ８３）。回答元決定フラグ１８５が“０”の場合、状
態監視部４は送信する送信するデータ項目に付属する確
度フラグ１６２を“０”に設定する（ステップ８６）。
回答元決定フラグ１８５が“１”の場合は、送信するデ
ータ項目に付属する確度フラグ１６２は“１”に設定さ
れる（ステップ８５）。

【００４７】以上のようにして確度フラグ１６２に
“１”が設定されるようなデータ項目は、そのデータが
確定しているものである。このようなデータは第１の実
施の形態における確定データに相当するものであり、以
降、本実施の形態においても同様に、確定データと呼
ぶ。また、上述した処理により確度フラグが“０”にな
るような状態のデータは、未確定データと呼ぶ。

【００４８】図１６は、ステップ７６で行われるデータ
の先行引取判定処理の詳細なフローチャートである。状
態監視部４は、選択されたデータ及びフラグについて、
合議フラグ１８１の値を判定する（ステップ９１）。合
議フラグ１８１が“０”場合、状態監視部４は、そのデ
ータ項目の決定フラグ１８２の判定を行う（ステップ９
２）。決定フラグ１８２が“１”の場合は、先行引取が
生じないのでそのままステップ３３の処理に移る。決定
フラグ１８２が“０”の場合、状態監視部４はさらに、
引取フラグ１８３の判定を行う（ステップ９３）。引取
フラグ１８３が“１”のであれば、状態監視部４はクラ
イアント２へ送信するデータ項目に付属する先行引取フ
ラグ１６３を“１”に設定した後ステップ３３に移る
（ステップ９９）。引取フラグ１８３が“０”であれ
ば、先行引取は行われていないものとしてステップ３３
の処理に移る。

【００４９】ステップ９１において合議フラグ１８１が
“１”であった場合、状態監視部４は、他部門引取フラ
グ１８９に基づき他部門によりデータが引き取られてい
るか否か判定する（ステップ９４）。他部門引取フラグ
１８９が“１”のとき、状態監視部４は、依頼元決定フ
ラグ１８４、及び回答元決定フラグ１８５に基づいて、
合議回答元が合議依頼元からデータを引き取ったか否
か、並びに、合議依頼元が合議回答元からデータを引き
取ったか否かについて判定する（ステップ９５）。依頼
元決定フラグ１８４と回答元決定フラグ１８５の両方が
“１”の場合は、先行引取が生じないので、状態監視部
４はそのままステップ３３の処理に移る。依頼元決定フ
ラグ１８４と回答元決定フラグ１８５の両方が“１”で
ない場合、すなわち依頼元決定フラグ１８４と回答元決
定フラグ１８５の少なくともいずれか一方が“０”に設
定されている場合、状態監視部４は送信するデータ項目
に付属する先行引取フラグ１６３を“１”に設定する
（ステップ９９）。このように、他部門引取フラグ１８
９が“１”の場合、依頼元決定フラグ１８４及び回答元
決定フラグ１８５の両方に“１”が設定されていなけれ
ば、そのデータは他部門によって先行引取されたことと
なる。

【００５０】ステップ９４において、他部門引取フラグ
１８９の値が“０”であった場合、状態監視部４は、ユ
ーザが他部門か否か判定する（ステップ９６）。ユーザ
が他部門の場合には、先行引取でないのでそのままステ
ップ３３の処理に移る。ユーザが他部門でなく、合議依
頼元か合議回答元である場合、状態監視部４は、依頼元
引取フラグ１８７に基づいて合議依頼元がデータを引き
取ったか否か判定する（ステップ９７）。依頼元引取フ
ラグ１８７が“１”の場合には、送信するデータ項目に
付属する先行引取フラグ１６３に“１”が設定される
（ステップ９９）。依頼元引取フラグ１８７が“０”の
場合には、さらに回答元フラグ１８８に基づいて合議回
答元がデータを引き取ったか否かが判断される（ステッ
プ９８）。回答元引取フラグ１８８が“１”の場合、状
態監視部４は送信するデータ項目に付属する先行引取フ
ラグ１６３を“１”に設定し（ステップ９９）、回答元
引取フラグ１８８が“０”の場合にはそのままステップ
３３の処理に移る。

【００５１】図１７は、ステップ７８で行われる引取フ
ラグ設定処理の流れを示すフローチャートである。掲示
板データベース１８において合議フラグ１８１が“１”
であるデータ項目について、クライアント２から受信し
た対応する引取フラグ１６４が“１”であるとき、つま
りクライアント２においてユーザによりデータの引き取
りの操作がされたとき、状態監視部４は以下の処理を行
う。まずユーザの識別を行い、ユーザが合議依頼元又は
合議回答元であるか否か判定する（ステップ１０１）。
判定の結果、ユーザがユーザが合議依頼元及び合議回答
元のいずれでもない他部門のユーザである場合、状態監
視部４は合議実施フラグ１８６の判定を行う（ステップ
１０２）。本実施の形態では、「一回でも合議を行って
いない合議を必要とするデータを他部門のユーザが引き
取ることはできない」というルールに基づいて処理が行
われる。このため、合議が実施され、合議実施フラグ１
８６が“１”にならない限り他部門のユーザはそのデー
タを先行引取することができない。ステップ１０２にお
いて合議実施フラグ１８６が“１”でないと判定された
場合は、先行引取はできないので、状態監視部４は、要
求のあったクライアント２へエラーメッセージを送り処
理を終える（ステップ１１０）。合議実施フラグが
“１”であれば、次に、依頼元決定フラグ１８４と回答
元決定フラグ１８５の判定を行う。この判定は、該当す
るデータの引取が、先行引き取りとなるか否かを区別す
るために行われる（ステップ１０３）。依頼元決定フラ
グ１８４と回答元決定フラグ１８５の両方が“１”の場
合には、先行引取にはならないのでここでの処理は終了
する。依頼元決定フラグ１８４と回答元決定フラグ１８
５の両方が“１”でない場合、状態監視部４は他部門引
取フラグ１８９に“１”を設定して処理を終了する（ス
テップ１０４）。ステップ１０１において、ユーザが合
議依頼元又は合議回答元であると判定された場合は、次
に、ユーザが合議依頼元であるか否かの判定を行う（ス
テップ１０５）。ユーザが合議依頼元である場合、回答
元決定フラグ１８５の判定を行う（ステップ１０６）。
回答元決定フラグ１８５が“１”、すなわちデータが決
定状態にあるときは、先行引取にはならないのでそのま
ま処理は終了する。回答元決定フラグ１８５が“１”で
ない場合、すなわちデータが未決定状態にあるとき、状
態監視部４は、合議回答元による決定がされないうちに
合議依頼元がデータを引き取ったことを示すために、依
頼元引取フラグ１８７に“１”を入れて処理を終える
（ステップ１０７）。また、ステップ１０５において、
ユーザが合議回答元であると判定された場合、状態監視
部４は、依頼元決定フラグ１８４の判定を行う（ステッ
プ１０８）。依頼元決定フラグ１８４が“１”、すなわ
ちデータが決定状態にあるときは、先行引取にならない
のでそのまま処理を終了する。依頼元決定フラグ１８４
が“１”でない場合、すなわちデータが未決定状態にあ
るとき、状態監視部４は、合議依頼元による決定がされ
ないうちに合議回答元がデータを引き取ったことを示す
ため、回答元引取フラグ１８８に“１”を入れて処理を
終了する（ステップ１０９）。

【００５２】以上の処理の結果、サーバ１から送られる
掲示板データにしたがってクライアント２の表示装置２
１に掲示板データがどのように表示されるか、以下、い
くつかの例を挙げて具体的に説明する。

【００５３】図１８は、クライアント２の表示装置２１
に表示される掲示板の第１の表示例であり、主に、各デ
ータについて、担当者、あるいは管理者により意思決定
がなされたか否かが画面上でどのように表されるかを説
明するための図である。ユーザ入出力部２３はサーバ１
から送られてきた掲示板の各データ項目についてデータ
の表示を行うとともに、各データ項目に付属の決定フラ
グ１６１にしたがって、表示されたデータに対応するラ
ジオボタンをオン又はオフにして表示する。図におい
て、白抜きの丸で表されるのがオフ状態のラジオボタン
であり、丸の中に黒いドットが表示されたものがオン状
態のラジオボタンである。各ラジオボタンは、それが対
応するデータについて担当者や管理者が意思決定したか
否かを表している。図１８に示す例では顧客名と商品名
のすべてのデータが決定しており、これらのデータに対
応するラジオボタンがオンになっている。一方、数量、
納入価及び納期というデータ項目については、ラジオボ
タンがオフとなっており、まだ意思決定されていないこ
とを表している。なおユーザはラジオボタンを押下する
ことによってオフ表示をオン表示に変更でき、この結果
は対応するデータ項目の決定フラグ１６１としてサーバ
１へ送られる。

【００５４】図１９は、表示装置２１に表示される掲示
板の第２の表示例であり、主として、表示される各デー
タについてその確度の確定・未確定が画面上でどのよう
に表示されるかを説明するための図である。ユーザ入出
力部２３はサーバ１から掲示板のデータを受け取ると、
各データ項目に付属の確度フラグ１６２の値にしたがっ
て各データを太字又は細字で表示装置２１に表示する。
この例では、顧客名と商品名のデータが太字で表示され
ている。これによりユーザは、顧客名と商品名について
はデータが確定していることを認識することができる。
一方、数量、納入価及び納期の各データは細字で表示さ
れており、まだ確定していないことがわかる。

【００５５】図２０は、表示装置２１に表示される掲示
板の第３の表示例であり、主に、データの確度が画面上
でどのように表示されるかを説明するための図である。
ここでは、クライアント２のユーザが営業担当者である
場合の表示装置２１に表示される表示画面を仮定して説
明を行う。なお、顧客名及び商品名については、営業担
当者の意思決定によりデータが確定し、納入価格は営業
担当者が決定したデータに対して営業課長が決済するこ
とで、すなわち、合議によりデータが確定するものとす
る。また、数量と納期については、営業担当者と倉庫担
当者の合議により確定するものとする。この例では顧客
名、商品名は、太字で表示されており営業担当者により
意思決定がなされ、確定していることがわかる。また、
テレビの納入価及びビデオの納入価も太字で表示されて
おり、営業担当者により意思決定がされ、営業課長によ
り決済がなされてデータが確定していることがわかる。
一方、エアコンの納入価については、ラジオボタンはオ
ンであるが、データは細字で表示されている。したがっ
て、営業担当者の意思決定はされているが、営業課長に
よる決済がされておらず、未確定のデータであることが
わかる。同様に、各商品の数量についても、ラジオボタ
ンがオンで、細字で表示されているので、このクライア
ント２を操作する営業担当者により決定されているが、
倉庫担当者による決定が未だされていないことがわか
る。納期についてはデータは設定されているが、営業担
当者はまだ意思決定をしていないのでラジオボタンがオ
フになっている。

【００５６】図２１は、表示装置２１に表示される掲示
板の第４の表示例であり、主に、引き取られたデータを
表示する表示画面を説明するための図である。ここでは
各データの確定状態が図２０に例示したものと同じであ
るものとし、このような状態で、倉庫担当者によりデー
タ項目が「顧客名」、「商品名」、「数量」、「納期」
のデータが引き取られているものとして説明する。営業
担当者の操作するクライアント２の表示装置２１には、
図２１に示すような掲示板が表示される。本実施の形態
では、先行して引き取られた未確定データは、通常に引
き取られた確定データと区別できるように下線を付して
表示される。図に示す例では、顧客名、商品名というデ
ータ項目のデータは確定データであることから、倉庫担
当者によりこれらのデータが引き取られていてもこれら
のデータに下線は付されない。「数量」というデータ項
目のデータについては合議の必要があり、未確定ではあ
るが営業担当者による意思決定はされている。また、倉
庫担当者はこのデータ項目に関しては合議回答元となる
ため、合議依頼元である営業担当者による意思決定が行
われていれば通常引取とみなされ、先行引取を意味する
下線は表示されなデータ項目の“６／１０”というデー
タは営業担当者による意思決定がされていないので、合
議回答元である倉庫担当者により引き取られたことを表
すために下線が表示される。

【００５７】以上説明した実施の形態によれば、複数の
作業工程の担当者の意思決定を反映する合議の形でデー
タの確定をし合議の結果をユーザに通知するとともに未
確定なデータを先行して引き取ったことをデータ入力し
たユーザに通知するので、他のユーザのとったアクショ
ンについて状況把握をしながら作業を進めることができ
る。なお、本実施の形態では合議回答元がただ１つの部
門である場合を例に説明した。合議回答元が複数部門あ
る場合も上記実施の形態と同様に実現することができ
る。この場合には、上記実施の形態において、回答元決
定フラグの判定を行う処理において、すべての合議回答
元に対応する回答元決定フラグが“１”に設定されたと
きに合議回答元でデータが決定したものとして扱えばよ
い。

【００５８】（第３の実施の形態）第１及び第２の実施
の形態では、掲示板の状態を所定のデータ項目が確定状
態となったときに状態が遷移する。データ項目に対して
データが確定入力されていく形態としては次のような形
態が考えられる。まず第１は、１つのデータ項目につい
て取り得るデータが１つしかない形態である。この場
合、１つの掲示板は１つのレコードで構成される。第２
は、少なくとも１つのデータ項目について取り得るデー
タが２つ以上あるものである。この場合は、１つの掲示
板が複数レコードで構成される。掲示板を構成するレコ
ードが単一のときと複数のときとではその掲示板にデー
タを格納する方法も異なってくる。単一レコードの掲示
板では、すべてのデータ項目に入力されたデータに対し
て掲示板上の作業状態が反映されるようにデータがデー
タベースに格納されなければならない。一方、複数レコ
ードからなる掲示板ではデータ項目に対して部分的にし
かデータが入力されていなくても、各レコードごとに掲
示板の状態を遷移することができる。例えば、商品名と
いうデータ項目内にデータとして複数の商品の名称が登
録されるような掲示板の場合、このデータ項目のデータ
がすべて確定入力されていなくても、一つ一つのデータ
ごとに状態を確定していくことができる。また、複数レ
コードからなる掲示板では、各レコードの状態の組み合
わせによって状態を判定するようにすることもできる。
このように、ユーザによって同じようなデータ項目でも
データの確定する形式が違ってくることが考えられる。
そこで、本実施の形態では、データの確定に対する掲示
板の状態の遷移に柔軟性を持たせ、実際の業務形態にあ
わせた柔軟な運用を行えるようにした。

【００５９】図２２は、本発明による第３の実施の形態
の業務処理システムの構成図である。本実施の形態にお
ける業務処理システムは、状態遷移ルール２７の構造、
および状態監視部５により実現される機能の一部が第２
の実施の形態と異なる点を除いて、基本的には、第２の
実施の形態と同様の構成を有する。したがって、ここで
は、第２の実施の形態と共通する部分については、第２
の実施の形態の説明で用いた参照符号を流用して説明を
行う。

【００６０】図２３は、本実施の形態における状態遷移
ルール２７のデータ形式を示す図である。本実施の形態
における状態遷移ルール２７は、各作業工程ごとに、そ
の作業工程の業務を行うために決定していることが必要
となるデータ項目を定義している。図２３では、掲示板
番号“００１”で識別される掲示板を用いて進められる
業務について定義された状態遷移ルール２７を示してい
る。なお、状態遷移ルール２７は、どの作業工程による
作業に遷移することが可能であるかを示しており、次の
作業工程に遷移するために必要な条件を定義している第
１の実施の形態の状態遷移ルール１２及び第２の実施の
形態の状態遷移ルール２０とは異なっている。図２３に
おいて、作業工程２７１には、業務における各作業工程
が登録される。掲示板番号２７２には、繊維状態の定義
が行われる掲示板の掲示板番号が登録される。状態定義
欄２７３〜２７７は、掲示板データベース１８の各デー
タ項目に対応しており、各作業工程において、その作業
工程の業務を行うために対応するデータ項目のデータが
満たさなければならない状態が設定される。“−”が設
定されている状態定義欄については、対応する作業工程
における処理を実施するためにそのデータ項目のデータ
が確定している必要がないことを示している。入力され
るべきデータが複数あるデータ項目が存在する場合、作
業に必要なデータ項目について、そのデータ項目の全て
のデータが確定しなければならないものには“ＡＬＬ”
が設定される。そのデータ項目のいずれかのデータが確
定していればよい場合には、状態定義欄に“ＥＡＣＨ”
が設定される。また、１つのデータしか与えられないデ
ータ項目について、そのデータが確定している必要があ
る場合は、状態定義欄に“ＡＬＬ”が設定される。な
お、１つのデータしか与えられないデータ項目について
は、複数のデータが与えられるデータ項目と区別するた
めに、そのデータが確定していることが必要であること
を示すために、例えば、“確定”などの情報を設定する
ようにしてもよい。図２３に示す例では、「引合」の作
業工程は、一連の業務の中で最初の作業工程であり、全
てのデータが未確定の状態で業務が行われるため、全て
のデータ項目について状態定義欄２７３〜２７７に
“−”が設定されている。また、「在庫確認」の作業工
程は、顧客名（１つの掲示板は、「顧客名」に１つのデ
ータのみが与えられるものとする）の他、いずれかの商
品について、商品名とその数量確定していればよいこと
を定義する。したがって、顧客名に対応する状態定義欄
２７３には“ＡＬＬ”が、商品名と数量に対応する状態
定義欄２７４、２７５には“ＥＡＣＨ”が設定される。
さらに、「価格見積」の作業工程では、納期以外のデー
タ項目でデータが確定している必要があることから、納
期に対応する状態定義欄２７７を除く状態定義欄２７３
〜２７６に“ＡＬＬ”が設定される。

【００６１】なお、本実施の形態の状態遷移ルール２７
は、作業工程の状態遷移についてそれに必要な条件を定
義しているに止まっており、掲示板データベースへのデ
ータの入力・更新の履歴を取ることができない。履歴の
取得が必要であれば、先に説明した実施の形態のよう
に、各データ項目ごとに、入力されるデータとそのデー
タ項目に対応する属性情報を登録できるようにすること
で対応できる。あるいは、履歴取得用のファイルを別途
用意するようにしてもよい。

【００６２】本実施の形態において状態監視部５により
行われる処理は、第２の実施の形態で状態監視部４が行
う処理と次の２点を除くとほぼ同じである。状態遷移が
あったかどうかを判定するための処理（ステップ３９）
において行われる判定処理が異なる。また、状態遷移ル
ール２７に履歴を残さないため、状態遷移ルールの更新
処理（ステップ３７）は行われない。図２４に本実施の
形態で状態監視部５により行われる状態遷移の判定処理
のフローチャートを示す。状態監視部５は、状態遷移ル
ール２７を参照して、現在の作業工程の次の作業工程に
ついての定義情報を取得する（ステップ３００）。取得
した定義情報の内、“ＡＬＬ”が設定されいるデータ項
目について、全てのデータが確定しているか判定する
（ステップ３０１）。“ＡＬＬ”が設定されいるデータ
項目について、全てのデータが確定していればさらに、
定義情報として、“ＥＡＣＨ”が定義されているデータ
項目について、定義情報が満足されているか判定する。
具体的には、掲示板データベースのレコードの中で、状
態遷移ルール２７により“ＥＡＣＨ”が設定されている
データ項目について全てのデータが決定しているレコー
ドがあるか調べる。このようなレコードがあれば、定義
情報“ＥＡＣＨ”が満足されていることになる（ステッ
プ３０２）。定義情報“ＥＡＣＨ”についても満足され
ていれば、次作業工程への状態遷移が可能であるので、
状態遷移があったものと判定する（ステップ３０３）。
一方、ステップ３０１、またはステップ３０２におい
て、条件を満足しないと判定された場合、状態遷移がな
いものと判定される（ステップ３０４）。

【００６３】以上述べたように第３の実施の形態によれ
ば、状態の遷移の仕方をデータ項目ごとに細かく設定す
ることができる。これにより、各ユーザは案件毎あるい
は案件に含まれるデータ項目のデータに対して、現在の
作業状態をお互いに認識でき、他の作業者との連携をよ
りスムーズに快適に図ることができる。なお、上記実施
の形態において、状態遷移期限ルールに登録されるデー
タ項目、及びそのデータ項目に対応する属性情報につい
て、掲示板データベースにあるデータを用いるようにす
れば、状態遷移期限ルールにこれらのデータを登録する
必要をなくすことができる。この場合には、ステップ４
２における処理を省略することが可能である。また、本
実施の形態においては、掲示板データベースは、業務処
理により入力・更新されるデータを保持するようにし、
業務処理で更新されることのない合議フラグを掲示板デ
ータベースとは別に設けるようにしてもよい。

【００６４】上記実施の形態では掲示板データベースに
現在の作業工程を識別可能とするためにステータスに関
する情報を持たせているが、このデータを掲示板データ
ベースに持たせないようにすることも可能である。この
場合、ステータスを知る必要があるときには、掲示板デ
ータベース内の属性情報に基づいて、各データ項目の確
定状態を調べ、その結果から状態遷移ルールを参照して
現在のステータスを求めればよい。また、状態を遷移さ
せるかどうかの判定を行うためには、クライアントから
送られてきたデータにより掲示板データベースを更新す
る前の段階で一旦ステータスを求めてそれを保持してお
く。そして、ステップ３９において掲示板データベース
を更新した後に求まるステータスと保持されているステ
ータスを比較することで状態が遷移したかどうかを判定
するようにすればよい。

【００６５】

【発明の効果】以上述べたように本発明によれば、業務
処理に関するすべてのデータ項目の内容が掲示板型デー
タベースの形式で関連するすべての担当者に開放され
る。このため、各担当者はいつでも業務処理の進行を見
ることができ、作業効率の向上に効果が大きい。

【図面の簡単な説明】

【図１】第１の実施の形態における業務処理システムの
構成図である。

【図２】掲示板データベースのデータ形式の例を示す図
である。

【図３】状態遷移ルールのデータ形式の例を示す図であ
る。

【図４】状態遷移期限ルールのデータ形式の例を示す図
である。

【図５】メッセージファイルのデータ形式の例を示す図
である。

【図６】宛先ファイルのデータ形式の例を示す図であ
る。

【図７】第１の実施の形態での掲示板の表示例を示す図
である。

【図８】状態監視部の処理の流れを示すフローチャート
である。

【図９】後工程の先行入力に関する処理の流れを示すフ
ローチャートである。

【図１０】第２の実施の形態における業務処理システム
の構成図である。

【図１１】掲示板データベースのデータ形式を示す図で
ある。

【図１２】アクセス権限ファイルのデータ形式を示す図
である。

【図１３】サーバとクライアントとの間で送受信される
データの形式を示すフォーマット図である。

【図１４】状態監視部の処理の流れを示すフローチャー
トである。

【図１５】データの確度判定処理の流れを示すフローチ
ャートである。

【図１６】データの先行引取判定処理の処理の流れを示
すフローチャートである。

【図１７】引取フラグ設定処理の処理の流れを示すフロ
ーチャートである。

【図１８】表示装置に表示される掲示板データの表示例
を示す図である。

【図１９】表示装置に表示される掲示板データの表示例
を示す図である。

【図２０】表示装置に表示される掲示板データの表示例
を示す図である。

【図２１】表示装置に表示される掲示板データの表示例
を示す図である。

【図２２】第３の実施の形態における業務処理システム
の構成図である。

【図２３】状態遷移ルールのデータ形式の例を示す図で
ある。

【図２４】状態遷移の有無を判定するための処理のフロ
ーチャートである。

【図２５】業務プロセスの一例を示す業務フロー図であ
る。

【符号の説明】

１…サーバ ２…クライアント ３、４、５…状態監視部 １１、１８…掲示板データベース １２、２０、２７…状態遷移ルール １３…状態遷移期限ルール １４…メッセージファイル １５…宛先ファイル １６…ファイル管理部 ２１…表示装置 ２２…入力装置 １９…アクセス権限ファイル ７０…ネットワーク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 永山 聡子 神奈川県横浜市都筑区加賀原二丁目２番 株式会社日立製作所ビジネスシステム開発 センタ内 (72)発明者 小川 誠 神奈川県横浜市都筑区加賀原二丁目２番 株式会社日立製作所ビジネスシステム開発 センタ内 (72)発明者 津坂 裕二 愛知県名古屋市中区栄三丁目10番22号 日 立中部ソフトウェア株式会社内 (72)発明者 細田 直文 神奈川県横浜市都筑区加賀原二丁目２番 株式会社日立製作所ビジネスシステム開発 センタ内

Claims (24)

【特許請求の範囲】
1. 【請求項１】複数の作業工程のシーケンスから構成され
   る業務処理の流れを通じて、該業務処理の結果として前
   記複数の作業工程のそれぞれの担当者によって端末装置
   からデータ入力されるデータ項目を複数個保持し、前記
   担当者のすべてに開示される掲示板データベースを格納
   する第１の記憶装置と、前記複数の作業工程の各々につ
   いて、作業工程が遷移するために前記複数のデータ項目
   が満たすべき状態を設定する状態遷移ルールを格納する
   第２の記憶装置と、前記第１の記憶装置及び前記第２の
   記憶装置にアクセスする情報処理装置によつて実行され
   る業務処理方法であって、 前記端末装置から前記掲示板データベースへのデータの
   入力要求を受け付け、 該入力要求に応答して、前記掲示板データベースの該当
   するデータ項目のデータの更新を行い、 前記状態遷移ルールに基づいて、作業工程の遷移可能か
   否かを判定し、 該判定の結果、作業工程の遷移が可能と判断されたと
   き、新たに作業を行うことが可能となった作業工程の作
   業を行う担当者の端末装置へ作業工程が遷移した旨の通
   知をすることを特徴とする業務処理方法。
2. 【請求項２】前記掲示板データベースはさらに、現在作
   業中の状態にある作業工程の識別子を現在工程として保
   持し、前記通知ステップは、前記識別子を現在工程の識
   別子から新たに作業を行うことが可能となった作業工程
   の識別子に更新するステップを含むことを特徴とする請
   求項１記載の業務処理方法。
3. 【請求項３】前記状態遷移ルールは、前記複数の作業工
   程の各々について前記複数のデータ項目のそれぞれがデ
   ータ入力を完了すべきデータ項目であるか否かを示す情
   報を有し、前記判定ステップは、現在工程について設定
   されたデータ項目がすべてデータ入力を完了したとき次
   の作業工程に遷移可能であることを判定することを特徴
   とする請求項１記載の業務処理方法。
4. 【請求項４】前記状態遷移ルールの、前記複数の作業工
   程の各々について入力されるデータの確度が確定か未確
   定かを示す確度情報を有しており、前記判定ステップ
   は、前記入力要求に基づいて前記確定情報に対応するデ
   ータが確定しているか未確定であるかを設定し、データ
   入力を完了すべきことが示されるデータ項目のデータが
   全て確定となったとき、次の作業工程に遷移可能である
   と判定することを特徴とする請求項３記載の業務処理方
   法。
5. 【請求項５】請求項１記載の業務処理方法において、さ
   らに、上記情報処理装置によりアクセスされ、処理期限
   のある該作業工程の各々についてデータ入力を完了すべ
   き期限を設定する期限ルールを格納した第３の記憶装置
   を設け、前記要求受け付けステップでは、前記期限ルー
   ルに基づいて、現在の期日が現在の工程について設定さ
   れている前記処理期限を過ぎているか否かを判定するス
   テップと、処理期限を過ぎていると判定されたとき、前
   記端末装置にデータ入力ができないことを通知すると共
   に、前記端末装置からのデータ入力を禁止するステップ
   を含むことを特徴とする業務処理方法。
6. 【請求項６】請求項５記載の業務処理方法において、前
   記期限ルールに基づいて現在の期日が、現在工程につい
   て設定されている処理期限より前のあらかじめ定めた期
   日になっているか判定し、前記あらかじめ定めた期日に
   なっていると判定されたとき、現在の作業工程の作業を
   行う担当者の端末装置に期限が迫っている旨の通知をす
   ることを特徴とする業務処理方法。
7. 【請求項７】前記更新ステップが、前記入力要求により
   入力を要求した担当者が、現在の工程よりも後の工程の
   担当者か否か判定するステップと、前記入力を要求した
   担当者が前記後の工程の担当者であると判定されたと
   き、さらに、前記入力要求により更新すべき前記掲示板
   データベースのデータ項目に対応して、データの先行入
   力が行われたことを示す先行入力フラグを設定するステ
   ップとを有することを特徴とする請求項３記載の業務処
   理方法。
8. 【請求項８】前記更新ステップが、前記判定するステッ
   プにおいて、前記入力を要求した担当者が前記後の工程
   の担当者ではないと判定されたとき、前記掲示板データ
   ベースのデータ項目の中に前記先行入力フラグが設定さ
   れている未確定の先行入力データに対して変更が行われ
   たか否か判定するステップと、前記先行入力データに対
   して変更が行われたと判断されたとき、前記後の工程の
   担当者の端末にデータ変更の通知を行うステップとを有
   することを特徴とする請求項７記載の業務処理方法。
9. 【請求項９】前記掲示板データベースは、各データ項目
   ごとに、入力されたデータの確度が確定か未確定かを示
   す確度情報を有し、前記判定ステップは、前記状態遷移
   ルールにより前記データ入力を完了すべきことが示され
   るデータ項目のデータが全て確定となったとき、次の作
   業工程に遷移可能であると判定することを特徴とする請
   求項１記載の業務処理方法。
10. 【請求項１０】前記掲示板データベースは、各データ項
    目ごとに、設定されたデータがいずれかの担当者の端末
    により引き取られていることを示す引取フラグを有して
    おり、前記確度情報により未確定であることが示される
    データ項目であって、前記引取フラグが設定されている
    データ項目があるか判定し、該当するデータ項目が存在
    する場合に、前記端末からの掲示板データベース転送要
    求に応答して、要求された掲示板データベースのデータ
    共に、前記該当するデータ項目のデータに対して引き取
    りが行われていることを通知する情報を転送することを
    特徴とする請求項９記載の業務処理方法。
11. 【請求項１１】前記掲示板データベースは、各データ項
    目ごとに、設定されるデータが確定するために合議が必
    要であるか否かを示す合議フラグを有し、該合議フラグ
    により合議が必要であることが示されるデータ項目の確
    度情報として、合議に参画する各担当者ごとに、設定さ
    れているデータに対する意思決定をしているか否かを示
    す決定フラグを有し、前記判定ステップは、前記状態遷
    移ルールにより前記データ入力を完了すべきことが示さ
    れるデータ項目であって、前記合議フラグにより合議を
    必要とすることが示されるデータ項目について、前記決
    定フラグの全てが担当者の意思決定があったことを示し
    ているか否かを判定するステップと、前記決定フラグの
    全てが担当者の意思決定があったことを示している場合
    に、当該データ項目に設定されたデータが確定している
    ものと判定するステップを含むことを特徴とする請求項
    ９記載の業務処理方法。
12. 【請求項１２】前記掲示板データベースは、前記データ
    項目ごとに、設定されたデータが確定しているか否かを
    示す確度情報を有し、前記状態遷移ルールは、前記業務
    処理の各作業工程に対応して、前記掲示板データベース
    のデータ項目ごとに、その作業工程の処理を行うために
    データ項目が確定している必要があるか否かを示す状態
    遷移ルール情報を有し、前記判定ステップは、前記確定
    情報を参照して前記状態遷移ルールを調べ、処理を行う
    ことが可能な作業工程を判定するステップを含むことを
    特徴とする請求項１記載の業務処理方法。
13. 【請求項１３】前記掲示板データベースにおいて複数の
    データが設定されるデータ項目に対応した前記状態遷移
    ルール情報は、設定されるすべてのデータが確定してい
    る必要があるか、一部のデータが確定していればよいか
    を表す情報を含むことを特徴とする請求項１２記載の業
    務処理方法。
14. 【請求項１４】複数の作業工程のシーケンスから構成さ
    れる業務処理を実施するための業務処理システムであっ
    て、 前記複数の作業工程のそれぞれに配置される複数のクラ
    イアントと、 前記クライアントによって入力更新が行われ、前記業務
    処理において利用される複数のデータ項目を含む掲示板
    データを保持するデータベースと、 前記データベースが接続するサーバであって、前記クラ
    イアントからの要求に応じて前記データベースから前記
    要求に該当する掲示板データに属するデータを取りだし
    て前記クライアントに送り、及び前記該当する掲示板デ
    ータに含まれるデータ項目へのデータの入力、更新を制
    御するサーバと、 前記サーバによって所持され、前記掲示板データのデー
    タ項目の状態に応じて、前記掲示板データを用いて実行
    中の業務処理が前記複数の作業工程のいずれの作業工程
    にあるかを特定するための状態遷移ルールとを有するこ
    とを特徴とする業務処理システム。
15. 【請求項１５】前記掲示板データベースは、前記複数の
    データ項目のそれぞれについて、設定されたデータが確
    定したものであるか否かを表す確度情報を有することを
    特徴とする請求項１４記載の業務処理システム。
16. 【請求項１６】前記掲示板データベースは、前記複数の
    データ項目のそれぞれについて、設定されたデータを確
    定するために複数の担当者による合議が必要であるか否
    かを表す合議フラグを有することを特徴とする請求項１
    ５記載の業務処理システム。
17. 【請求項１７】前記掲示板データベースは、前記合議フ
    ラグによって合議が必要であることが必要とされるデー
    タ項目に対応する前記確度情報は、対応するデータ項目
    の決定に参画する各担当者ごとに、データ項目に設定さ
    れたデータに対する決定の意思が示されたか否かを表す
    決定情報を含むことを特徴とする請求項１６記載の業務
    処理システム。
18. 【請求項１８】前記掲示板データベースは、前記複数の
    データ項目のそれぞれについて、現在の作業工程よりも
    後の作業工程の担当者により対応するデータ項目にデー
    タが設定されたか否かを示す先行入力フラグを有するこ
    とを特徴とする請求項１５記載の業務処理システム。
19. 【請求項１９】前記状態遷移ルールは、前記業務処理を
    構成する各作業工程に対応して、前記掲示板データのデ
    ータ項目ごとにそのデータ項目に対して設定されるデー
    タが満たすべき状態を示す状態遷移ルール情報を有する
    ことを特徴とする請求項１４記載の業務処理システム。
20. 【請求項２０】前記状態遷移ルール情報は、次の作業工
    程に遷移するためにそれが対応するデータ項目に設定さ
    れたデータが確定している必要があるか否かを表すこと
    を特徴とする請求項１９記載の業務処理システム。
21. 【請求項２１】前記サーバは、前記状態遷移ルールに基
    づいて、前記掲示板データベースの各データ項目に設定
    されたデータが、次の作業工程に遷移可能か否かを判別
    し、遷移可能と判別されたときに次の作業工程のクライ
    アントに対して、作業工程の遷移あがったことを通知す
    ることを特徴とする請求項２０記載の業務処理システ
    ム。
22. 【請求項２２】前記状態遷移ルール情報は、対応する作
    業工程の業務処理を行うためにデータ項目に設定される
    データが確定している必要があるか否かを表すことを特
    徴とする請求項１９記載の業務処理システム。
23. 【請求項２３】前記状態遷移ルール情報は、対応するデ
    ータ項目に設定されるデータが複数ある場合に、全ての
    データが確定している必要があるか、一部のデータが確
    定していればよいかを表すことを特徴とする請求項２２
    記載の業務処理システム。
24. 【請求項２４】前記サーバは、前記状態遷移ルールに基
    づいて前記掲示板データにより行われている業務処理の
    作業工程のステータスを判別し、新たに作業が可能とな
    った作業工程のクライアントに対して、作業工程に遷移
    が生じたことを通知することを特徴とする請求項２２記
    載の業務処理システム。