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

Description

【０００１】
【発明の属する技術分野】
本発明は、複数の作業工程のシーケンスから構成されるワークフローにおいて、各作業工程が業務処理の結果として電子計算機にデータ入力するシステムに係わり、特に、すべての作業工程の担当者が単一の掲示板型データベースを共有する業務処理システム及びその方法に関する。
【０００２】
【従来の技術】
一般に、業務処理は、複数の作業工程のシーケンスから構成される業務処理プロセスを経て遂行されることが多い。ある作業工程から次の作業工程には、伝票、帳票等を通じて次々にデータが受け渡され、一連の業務プロセスが遂行される。電子計算機を利用するワークフローシステムでは、伝票や帳票を単位とする情報は電子計算機の記憶装置に格納され、ネットワークを介するデータ伝送によって次に作業を行う担当者に渡される。
【０００３】
図２５は、販売業務における業務プロセスの流れの一例を示す図である。図２５に示される業務プロセスでは、顧客への販売活動を行って引合の後に具体的に商品の仕様、価格、納期等の見積りが行われる。そして、契約が成立したら関連部署に資材調達、製品の設計や製造、在庫の引当、商品の搬入措置などの手配が行われる。さらに、商品を客先に納品し、検収を終えた後に代金の請求／回収が行われる。引合、見積など各段階は作業工程に相当する。従来技術によれば、ある作業工程から次の作業工程へのデータの受け渡しは、伝票を単位として行われる。このため、次の作業工程の担当者への情報の伝達は、伝票上のすべてのデータが揃った時点で行われる。したがって、次作業工程以降の担当者は、伝票上のデータがすべて確定するまでその内容を知ることができない。例えば、図２５に示す例において、引合、見積の段階で商品内容が確定しなくても納品管理の担当者が商品についてのデータを未確定情報として早く知りたいような場合、従来の方法では次作業工程以降の担当者は、その情報を知ることができない。また、業務処理の結果として電子計算機に入力されるデータのデータ項目についても、業務処理の流れに従って確定していくとは限らないし、どのデータ項目からデータが確定していくかは必ずしも一意に決められない。例えば、図２５における見積の段階で商品仕様の商談が先に進めば、これに関するデータ項目が先に確定する。逆に納期の商談が先に進めばこれに関するデータ項目が先に確定する。しかし、従来の方法によれば、データ項目が確定したときに関連部署の担当者に通知しようとすると、その作業工程の作業担当者がその都度関連部署の担当者の宛先とデータを指定して送信処理を行わねばならず、担当者の負担が大きくなるという問題がある。さらに、従来の方法によれば、一連の業務プロセスを通じて何種類もの伝票を作成するとともに同じデータを異なる伝票に何度も入力するいわゆる重複入力をするため、入力ミスを引き起こす可能性が大きくなるとともに、余計なデータ入力時間をかけることになる。
【０００４】
【発明が解決しようとする課題】
上述したように、従来技術によれば、ある作業工程から次の作業工程へのデータの伝達は、基本的に伝票を単位として行われるため、伝票上のすべてのデータが揃わないと次の作業工程にデータの伝達が行われなかった。したがって、後工程の作業者が先行して作業を進めようとしても作業を行えず、作業効率が上がらないという問題があった。そして、このような業務処理の直列的な流れに反して確定または未確定のデータを後工程の作業者に伝達しようとすると、作業者に負担を強いることになるという問題があった。また、伝票へのデータの重複入力による入力ミスや作業効率の問題があった。
【０００５】
本発明の目的は、上記問題点を解決し、業務処理システムにおいて、任意の担当者が任意の時点で必要とするデータを参照することを可能とすることにある。
【０００６】
本発明の他の目的は、ある作業工程から次の作業工程に遷移するときのデータの送受信を極力少なくし、これに伴う担当者の負担を軽減するとともにネットワークの負荷を軽減することにある。
【０００７】
本発明のさらに他の目的は、後工程の担当者が先行してデータを参照することを可能にするに止まらず、後工程の担当者が先行してデータを入力する操作を許可して作業効率を向上させるとともに、そのときに生じ易い混乱を防止できるようにすることにある。
【０００８】
【課題を解決するための手段】
本発明による業務処理システムは、一連の業務プロセスに関連するすべてのデータ項目の内容をデータベースに集約し、関連するすべての担当者がこのデータベースを共有できるようにすることを特徴とする。このとき、作業工程のシーケンスに従って現在作業中の工程という概念を保存して、現在工程の担当者が主としてデータ入力やデータ更新をするようにし、後工程の担当者が主としてデータ参照できるようにする。また、各作業工程について、データ項目ごとに、作業工程が遷移するために満足すべきデータの状態を状態遷移ルールとして定義しておく。この状態遷移に基づいて、作業工程に遷移が生じたか否か判断し、作業工程が遷移したと判断されたとき、新たに作業を行うことが可能となった作業工程の担当者に作業工程が遷移した旨の通知をする。
【０００９】
好ましい態様において、本発明の業務処理システムは、データベースに、現在の作業工程を表す識別子を設け、作業工程に遷移が生じたときは、新たに作業を行うことが可能となった作業工程を表す識別子に更新して、次の作業工程に遷移させる。
【００１０】
より好ましい態様において、本発明による業務処理システムでは、処理期限のある作業工程の各々について、データ入力を完了すべき期限を設定し、現在の作業工程がこの期限より前のあらかじめ定めた期日に来たとき、その担当者に期限が迫っている旨の通知をする。さらに、後工程の担当者からのデータの先行入力を許し、先行入力されたデータ項目に対応してフラグを立てる。前工程の担当者からのデータ入力の要求があったとき、フラグが立っている未確定のデータ項目を検出して後工程の担当者へ前工程によるデータ変更があった旨の通知をする。これにより、後工程の担当者が入力したデータを見直しできるようにする。
【００１１】
また、本発明による業務処理方法は、データベースの一部のデータ項目に対応して、複数の作業工程の担当者がそれぞれそのデータ項目のデータについて意思決定したか否かを示す情報を保持する。複数の作業工程の担当者がすべて意思決定したときワークフロー上のデータが確定したものとみなすとともに、担当者にデータの確定を通知することを特徴とする。
【００１２】
さらに本発明による業務処理方法は、データベースのデータ項目に対応して、確度が未確定なデータ項目のデータを先行して引き取っているか否かを示す情報を保持する。未確定なデータを先行して引き取っている場合には、担当者にその旨通知するようにしたことを特徴とする。
【００１３】
【発明の実施の形態】
（１）第１の実施の形態
図１は、本発明による第１の実施の形態の業務処理システムの構成図である。本実施の形態における業務処理システムは、業務上のデータを格納するデータベースと関連するファイル、このデータベースを監視するサーバ１及びネットワーク７０を介してサーバ１に接続され、データベースへのデータ入力と更新を行う複数のクライアント２から構成される。クライアント２は業務処理を遂行する各部署に配置される端末装置である。掲示板データベース１１は、業務処理に関する最新のデータを格納し、クライアント２に対して掲示板として機能するデータベースである。状態遷移ルール１２は、掲示板データベース１１上のデータ項目のデータ入力状況と入力されたデータの確度とから、業務処理の流れの中でどの作業工程の処理を完了させるかを定義するファイルである。状態遷移期限ルール１３は、各作業工程について処理を完了すべき期限を定義するファイルである。メッセージファイル１４は、関連部署へ通知するためのメッセージを格納するファイルである。宛先ファイル１５は、メッセージを送付する宛先を登録するファイルである。掲示板データベース１１、状態遷移ルール１２、状態遷移期限ルール１３、メッセージファイル１４及び宛先ファイル１５は、サーバ１に接続される記憶装置上に格納される。これらのデータベースやファイルへのアクセスの管理は、ファイル管理部１６によって行われる。
【００１４】
サーバ１の状態監視部３は、掲示板データベース１１と状態遷移ルール１２を参照してステータスを次の工程に遷移すべきか否かを判定し、遷移するときにはメッセージファイル１４及び宛先ファイル１５を参照して関連部署にメッセージを送信する。また状態監視部３は、状態遷移期限ルール１３を参照して現在の工程について処理期限が迫っているか否かを判定し、期限が迫っているときにはメッセージファイル１４及び宛先ファイル１５を参照して関連部署に警告のメッセージを送信する。さらに状態監視部３は、現在の工程より後の工程の業務担当者がデータの先行入力をしたか否かを監視し、先行入力したデータ項目にフラグを立て、それ以後に現在工程の担当者がデータを変更したとき、メッセージファイル１４及び宛先ファイル１５を参照して後工程の担当者へ注意のためのメッセージを送信する。通信制御部１７は、ネットワーク７０を介してクライアント２との間に行われるデータやメッセージの送受信を制御する制御部である。
【００１５】
クライアント２の表示装置２１は、掲示板やメッセージを表示する装置であり、具体的にはＣＲＴディスプレイなどが用いられる。入力装置２２は、掲示板上にデータを入力する装置であり、例えば、キーボード、マウスなどが用いられる。ユーザ入出力部２３は、ユーザインタフェースを実現する処理部であり、あらかじめ画面設計された表示画面の様式に従ってサーバ１から受け取ったデータを表示装置２１上に表示し、入力装置２２から入力されたデータを、サーバ１へ送信する。通信制御部２４は、ネットワーク７０を介してサーバ１との間で行われるデータやメッセージの送受信を制御する制御部である。サーバ１及びクライアント２は、パソコン、ワークステーションを含む情報処理装置によって構成される。状態監視部３、ファイル管理部１６、通信制御部１７、ユーザ入出力部２３及び通信制御部２４は、この情報処理装置のハードウェアによって又はその記憶装置に格納されるプログラムを実行することによって実現される。なお、掲示板データベース１１を始めとするデータベースやファイル及びファイル管理部１６をネットワークを介してサーバ１と接続される別のサーバによって実現してもよい。
【００１６】
図２は、掲示板データベース１１のデータ形式の例を示す図である。掲示板データベース１１は、少なくとも１組の掲示板データを保持している。各掲示板データは、項番１１０、掲示板番号１１１、ステータス１１２、複数のデータ項目１１３、及び各データ項目に対応してそのデータ項目に登録されたデータの状態を示す属性情報を含む。項番１１０は、テーブル内でのレコードの番号を表す。掲示板番号１１１は、掲示板データベース１１に格納されている個々の掲示板を区別するために付される識別子となる番号である。ステータス１１２は、業務プロセスの流れを通じて作業工程のシーケンスの順番に各工程の名称を設定する工程の識別子である。データ項目１１３は、業務処理の結果としてデータが入力される項目である。データ項目とは、例えば、一般的な事務処理で利用される伝票上の項目に相当するもので、データ項目１１３に設定されるデータは、伝票に記入されるデータに相当する。本実施の形態では、データ項目の具体例として「顧客名」、「商品名」、「受注数」、「納期」、「価格」、及び「納入場所」を例示している。各データ項目１１３には、そこに与えられるデータの状態を表す属性情報が付与されている。属性情報には、対応するデータ項目に入力されたデータが確定したものであるか未確定なものであるかを示す確度１１４と、後工程が先行してデータを入力したときに１が設定されるフラグ１１５が設けられる。本実施の形態では、確度１１４に「確定」が設定されたデータ項目の更新は、原則として禁止される。なお、掲示板データは、業務処理システムで行われる業務について、いわゆる掲示板のように、各クライアント２０から少なくともその一部を参照することが可能な情報である。業務処理システム上で処理される個々の一連の業務に対応して掲示板データは形成される。
【００１７】
図３は、状態遷移ルール１２のデータ形式の例を示す図である。状態遷移ルール１２は、データ項目のデータ入力状況と入力されたデータの確度とからどの作業工程の処理を完了させるかを定義するとともに、データ入力の履歴をも示している。図から理解されるように、掲示板データベース１１とほぼ同様の形式を有する。掲示板データベース１１は、現在の工程についての最新データのみを保持しているのに対し、状態遷移ルール１２は各作業工程ごとにレコードを有し、それぞれの作業工程において入力、更新されたデータを保持する。掲示板データベース１１の内容と状態遷移ルール１２の対応する作業工程の内容とは一致している。各作業工程においてデータ入力が必要とされないデータ項目には、初期状態において“未定”が設定される。状態遷移ルール１２は、初期状態ではステータス１２１と、“未定”が設定されたデータ項目以外の欄はスペースである。例えば「引合」の工程では、初期状態において、データ項目１２２の中で「納期」、「価格」、「納入場所」には、“未定”が設定されており、「顧客名」、「商品名」、「受注数」のデータ項目はスペースである。したがって、「顧客名」、「商品名」、「受注数」のデータ項目にデータ入力されるとスペースであったデータ項目がなくなるので、「引合」工程は完了となる。同様に「見積」工程では「納入場所」以外のすべてのデータ項目にデータ入力されるとスペースのデータ項目がなくなるので、「見積」工程は完了となる。本実施の形態では、データ項目の確度１２３がすべて確定でなければ次の工程に遷移できない。
【００１８】
図４は、状態遷移期限ルール１３のデータ形式の例を示す図である。ステータス１３１は、ステータス１１１と同じく業務フローを構成する工程を順に並べたものである。顧客名、形名及び納期は、業務に関するデータ項目である。処理期限１３２は、当該工程について処理を完了させねばならない締め切り日である。警告日１３３は、処理期限が迫っているとき処理期限１３２の何日前に警告メッセージを発行するかを示す。項番と掲示板番号は、掲示板データベース１１と同じである。初期状態ではステータス１３１の各工程名と警告日１３３だけが設定されている。業務に関するデータ項目は、掲示板データベース１１の更新に応じてその内容が反映される。処理期限１３２は、管理者によって設定される。
【００１９】
図５は、メッセージファイル１４のデータ形式の例を示す図である。ステータス１４１は、ステータス１１１と同じく業務フローを構成する工程を順に並べたものである。メッセージ１４２には、各工程について工程が遷移したとき、処理期限が迫ったとき及び前工程によつてデータ変更があったときに発行するメッセージが設定される。
【００２０】
図６は、宛先ファイル１５のデータ形式の例を示す図である。ステータス１５１は、ステータス１１１と同じく業務フローを構成する工程を順に並べたものである。宛先ファイル１５には、各工程対応に宛先情報としてメッセージを送付するときの宛先部署と担当者名が設定される。また宛先情報には、電子メールのアドレスを設定するようにしてもよい。
【００２１】
図７は、クライアント２の表示装置２１に表示される掲示板のデータ形式の例を示す図である。掲示板には、掲示板データベース１１の各データ項目の値が表示される。図７（ａ）は、納入場所以外のデータ項目についてデータ入力が済んでいる状態であり、ステータスが「見積中」であることを示している。また図７（ｂ）は、すべてのデータ項目についてデータ入力が済んでいる状態であり、ステータスが「受注」完了であることを示している。各データ項目の属性、すなわち確度の確定／未確定の区別及びフラグの有無は、そのデータ項目の表示色、ブリンク表示の有無等によって区別することができる。
【００２２】
図８は、状態監視部３の処理の流れを示すフローチャートである。クライアント２のユーザ入出力部２３から通信制御部２４及び通信制御部１７を介して掲示板番号、工程名、顧客名などを指定して掲示板の要求を受信したとき（ステップ３１）、状態監視部３は掲示板データベース１１を検索して、掲示板番号で指定された掲示板の情報を取り出す（ステップ３２）。そして、状態監視部３は、取り出した掲示板の情報を通信制御部１７を介してクライアント２へ送信する（ステップ３３）。クライアント２のユーザ入出力部２３はこの掲示板をオープンし、表示装置２１上に表示する。
【００２３】
クライアント２側で入力装置２２を介してデータ項目又は確度についてデータの入力又は更新があったとき、ユーザ入出力部２３は、通信制御部２４を介してサーバ１へこの入力／更新データを送信する。入力／更新データはサーバ１により受信され、状態監視部３に渡される（ステップ３４）。状態監視部３は、入力／更新データを受け取ると、状態遷移期限ルール１３を参照して、掲示板番号が一致しステータス１３１が現在の工程名に一致するエントリの処理期限１３２と現在日付とを比較する。この比較結果に基づいて、状態監視部３は、処理期限が過ぎているか否かを判定する（ステップ３５）。現在日付が処理期限を過ぎている場合は、データ入力元のクライアント２へデータ入力不可である旨のメッセージを送信し、処理を終了する（ステップ４５）。なおステップ３５では、現在の工程より前の工程についてクライアント２からデータ入力要求があった場合も処理期限が過ぎているものとみなしてステップ４５の処理に移る。処理期限が過ぎてからのデータ入力要求や状態遷移後の前工程についてのデータ更新は、特別の許可を得た場合を除いて禁止される。なお、現在の工程が処理期限１３２を過ぎていることを検出したとき、管理者等へメッセージを送信し、その旨通知するようにしてもよい。
【００２４】
一方、ステップ３５の判定の結果、現在日付が処理期限を過ぎていないことが確認されると、状態監視部３は、入力されたデータによって掲示板データベース１１を更新する（ステップ３６）。次に状態監視部３は、状態遷移ルール１２を参照して、掲示板番号が一致し、ステータス１２１が現在の工程名に一致するエントリのデータを最新データによって更新する（ステップ３７）。そして、後述する、後工程からのデータの先行入力の確認処理を行う（ステップ３８）。この後、状態監視部３は、状態遷移ルール１２を参照して状態遷移が生じたか否かを判定する。ここでは、状態監視部３は、ステータス１２１が現在の工程名に一致するエントリについて、“未定”が設定されたデータ項目を除くすべてのデータ項目にデータが入力され、その確度１２２がすべて「確定」であるとき、次の工程への遷移が生じたと判定する（ステップ３９）。
【００２５】
ステップ３９において状態遷移があると判定されたとき、状態監視部３は状態遷移期限ルール１３中の掲示板番号が一致し、ステータス１３１が現在の工程名に一致するエントリの内容を最新データによって更新する。また、掲示板データベース１１のステータス１１２を次の工程名に更新する（ステップ４０）。次の工程名は状態遷移ルール１２において、現工程の次のレコードのステータス１２１に登録されている。続いて、メッセージファイル１４及び宛先ファイル１５を参照して、次の工程の関連部署へ、前の工程のデータ入力が完了した旨のメッセージを送信し、処理を終了する（ステップ４１）。ここで送信されるメッセージは、メッセージファイル１４の掲示板番号が一致し、ステータス１４１が次の工程名であるエントリの該当するメッセージである。またメッセージの宛先は、宛先ファイル１５のステータス１５１が次の工程名であるエントリの宛先部署、担当者名等である。なお状態監視部３はメッセージとともに掲示板番号、データ入力が済んだデータ項目の名称とデータなど掲示板データベース１１から必要なデータを抽出してこの関連部署へ送信する。メッセージを受けた関連部署は、クライアント２及びサーバ１を介して掲示板をオープンすることができる。
【００２６】
ステップ３９において状態の遷移がないと判断されると、状態監視部３は状態遷移期限ルール１３を参照して、掲示板番号が一致し、ステータス１３１が現在の工程名に一致するエントリのデータを最新データによって更新する（ステップ４２）。次に、当該エントリの処理期限１３２及び警告日１３３を参照して現在日付が警告日１３３に設定する警告日に達しているか否かを判定する（ステップ４３）。期限が迫っていなければ、処理を終了する。期限が迫っていれば、メッセージファイル１４及び宛先ファイル１５を参照し、現在工程の関連部署へ期日が迫っている旨のメッセージを送信した後、処理を終了する（ステップ４４）。ここで送信するメッセージは、メッセージファイル１４の掲示板番号が一致し、ステータス１４１が現在の工程名であるエントリの該当するメッセージである。メッセージの宛先は、宛先ファイル１５のステータス１５１が現在の工程名であるエントリの宛先部署、担当者名等に基づき決定される。状態監視部３は、メッセージとともに掲示板番号、データ入力が済んだデータ項目の名称とデータ、データ未入力のデータ項目の名称など掲示板データベース１１から必要なデータを抽出してこの関連部署へ送信する。
【００２７】
図９は、ステップ３８で行われる後工程からのデータの先行入力の確認処理の流れを示すフローチャートである。ステップ３７から制御が移ったとき、状態監視部３は、後工程によるデータ入力か否かを判定する（ステップ６１）。後工程によるデータ入力か否かは、データ入力要求のあった工程名と掲示板データベース１１のステータス１１２にある現在の工程名とを比較することによって判定する。現在工程より後の工程の名称は、状態遷移ルール１２のステータス１２１に登録されており、確認可能である。後工程によるデータ入力であれば、掲示板データベース１１及び状態遷移ルール１２の先行入力されたデータ項目に対応するフラグ１１５、１２３をオンにして、ステップ３９の処理に移る（ステップ６２）。一方、ステップ６１で後工程によるデータ入力でないと判定されると、次に、先行して入力されているデータ項目があるか否かを判定する。掲示板データベース１１において現在工程のデータ項目の中でフラグ１１５がオンとなっているデータ項目があれば、そのデータ項目が先行入力されたデータ項目である（ステップ６４）。先行入力のデータ項目がなければ、そのままステップ３９へ行く。ステップ６４で先行入力のデータ項目があれば、そのデータ項目の確度の判定を行う（ステップ６５）。先行入力されたデータ項目に対応する確度１１４がすべて“確定”となっていれば、ステップ３９へ行く。先行入力されたデータ項目のいずれかの確度１１４が“未確定”ならば、続いて、前工程によるデータ変更があったか否かを判定する。データ入力要求のあった工程が現在の工程であって、業務に関するいずれかのデータ項目についてデータ入力又はデータ更新があったとき、前工程によるデータ変更に該当する（ステップ６６）。前工程によるデータ変更があったときは、メッセージファイル１４及び宛先ファイル１５を参照して、前工程からデータ変更があった旨のメッセージを関連部署へ送信する。送信するメッセージは、メッセージファイル１４の掲示板番号が一致し、ステータス１４１が現在の工程名より後にあるエントリの該当するメッセージである。またメッセージの宛先は、宛先ファイル１５のステータス１５１が現在の工程名より後にあるエントリの宛先部署、担当者名等である。なお状態監視部３はメッセージとともに掲示板番号、前工程によるデータ入力／更新のあったデータ項目の名称とデータなどを関連部署へ送信する（ステップ６７）。最後に掲示板データベース１１及び状態遷移ルール１２のフラグ１１５、１２３をすべてオフにして、ステップ３９へ行く（ステップ６９）。ステップ６５において前工程によるデータ変更がないと判定されたときは、そのままステップ３９に移る。
【００２８】
上記実施の形態によれば、掲示板データベース１１のステータスに格納される現在の工程より後の工程の業務担当者は先行してデータ入力や更新が可能である。しかし、現在工程がある特定の工程に到達したとき、その工程の処理が完了しない限り後工程が掲示板を参照するか又は先行入力する操作を許可しないように制約を設けてもよい。
【００２９】
また、上記実施形態によれば、現在の工程について設定された処理期限１３２に到達しなくとも、その工程に必要なデータ項目のデータ入力が終了し、入力されたデータの確度１１５が“確定”であれば自動的に次の工程に遷移するので、動的にワークフローを形成することができる。しかも状態遷移ルール１２に過去のデータ入力及び更新の履歴を残すので、必要に応じて過去のデータ入力／更新の状況をたどることができる。ただ、これだけでは、掲示板を見ない担当者がいるとワークフローの流れが停滞してしまう。そこで、本実施の形態では処理期限が迫ったとき、関連部署の担当者に警告メッセージを送ることによって遅れているデータ入力を促進することを可能としている。また現在の工程という概念を保存しながら後工程の作業者がデータ入力できるデータ項目については先行入力できるようにして作業効率を上げるようにした。ただし前工程（現在工程）が後からデータ変更することによって後工程が行ったデータ入力、特に未確定のデータ入力を見直す必要がある場合がある。本実施の形態では、前工程がデータ変更したとき後工程が未確定のデータを先行入力している場合にメッセージを送信するので、後工程がデータの先行入力をしても混乱が生じることはない。
【００３０】
（２）第２の実施の形態
第１の実施の形態によれば、１人の担当者がクライアント２を介して掲示板データベース１１の各データ項目について「確定」する旨入力すればそのデータ項目に対応する確度１２２が「確定」に設定され、データが確定した。１人の担当者の意思決定によってデータを確定してよいデータ項目についてはこの方法で充分である。しかし、データ項目によっては２つ以上の関連する部門の担当者がともに意思決定したり、担当者の意思決定の後に管理者の決裁を得て初めて、すなわち何らかの合議の結果としてデータを確定すべきデータ項目も存在する。第２の実施の形態ではこのような合議を必要とするデータ項目については、関連する部門のユーザがともに意思決定して初めて確定データとみなすとともに、ユーザの状況把握のために合議の状況を常時ユーザに通知可能とする。また、第１の実施の形態では、あるデータ項目について、後工程のユーザが先行入力したことは前工程のユーザに通知されるが、「未確定」のデータが他のユーザによって参照され作業のための基礎データとなったか否かを知る手段はない。第２の実施の形態では「未確定」のデータに基づいて他のユーザが作業を進めている、すなわち他のユーザが「未確定」データを引き取っていることをデータ入力したユーザが知り得るようにし、ユーザがこのような先行引取に伴う状況把握をできるようにした。
【００３１】
図１０は、本発明の第２の実施の形態における業務処理システムの構成図である。図１０において、図１と同一の参照番号が付されているものは、図１の対応する部分と同様の機能、構成を有する。掲示板データベース１８は、第１の実施の形態の掲示板データベースと同様に、クライアント２に対して掲示板として機能するデータベースであるが、そのデータ形式は、第１の実施の形態とは異なっている。状態遷移ルール２０も第１の実施の形態と機能的には同一であるが形式が異なる。状態遷移ルール２０が第１の実施の形態の状態遷移ルール１２と相違する点は、後述する掲示板データベース１８と第１の実施の形態の掲示板データベース１１の相違と共通するものであり、ここでは詳細な説明は省略する。アクセス権限ファイル１９は、掲示板データベース１８の各データ項目のデータ及び各種フラグについて、各作業工程のユーザごとに参照又は書き込みの可否を設定するファイルである。アクセス権限ファイル１９は、他のファイル類と同様に、サーバ１に接続される記憶装置上に格納される。サーバ１の状態監視部４は、第１の実施の形態における状態監視部３の機能の他、各データ項目のデータの決定状況の判定、データの確度の判定、データの先行引取の判定、及び関連するフラグの設定を行う機能を有する。クライアント２は、第１の実施形態のクライアント２と同様の機能を含んで構成される。サーバ１とクライアント２との間に送受信されるデータの形式が第１の実施の形態と異なるので、ユーザ入出力部２３の処理が第１の実施の形態とは多少異なるが、主たる機能としては大きく異なるものではないので、ここでは、第１の実施の形態と同一の参照番号を用いている。なお、以下の説明において、具体的な例を挙げて説明を行っている部分では、ユーザである営業担当者、営業課長及び倉庫担当者により図２５に例示した業務が行われることを想定している。
【００３２】
図１１は、掲示板データベース１８のデータ形式を示す図である。なお、以下の説明ではデータ項目として「顧客名」、「商品名」、「数量」、「納入価」及び「納期」がある場合を考える。本実施の形態の掲示板データベース１８は、各データ項目に対応して設定される属性情報が第１の実施の形態とは異なっている。本実施の形態では、データ項目に設定されたデータの状態を表す属性情報として、合議フラグ１８１、決定フラグ１８２、引取フラグ１８３、合議依頼元決定フラグ１８４、合議回答元決定フラグ１８５、合議実施フラグ１８６、合議依頼元引取フラグ１８７、合議回答元引取フラグ１８８及び他部門引取フラグ１８９が設けられる。合議フラグ１８１は、全てのデータ項目に対応して設けられ、対応するデータ項目の内容について、そのデータ項目に設定されたデータを確定するために複数の処理者による合議が必要であるか否かを示すフラグである。合議フラグ１８１が“０”であれば合議の必要がなく、“１”であれば合議を必要とする。合議フラグ１８１に“０”が設定されているデータ項目については、属性情報として、決定フラグ１８２、引取フラグ１８３が含まれる。決定フラグ１８２は、第１の実施の形態における確度１２２に相当するフラグであり、入力者が対応するデータ項目の内容について意思決定したか否かを表すフラグである。この場合は、決定フラグの状態が“１”になると、そのデータ項目に設定されているデータが確定データであることを意味する。引取フラグ１８３は、合議が必要ないデータ項目の未確定状態のデータについて、他部門が先行してデータを引き取っていることを表すフラグである。他部門により対応するデータ項目にデータが引き取られているとき、引取フラグ１８３に“１”が設定される。例えば、図１１において、データ項目「顧客名」に着目すると、合議フラグ１８１には“０”が設定されており、このデータ項目については合議が不要であることがわかる。そして、決定フラグ１８２には“１”が設定されており、このデータ項目に設定されているデータ“Ａ社”は確定していることが示されている。また、引取フラグ１８３にも“１”が設定されており、現在、他部門にデータが引き取られていることがわかる。
【００３３】
一方、合議フラグ１８１が“１”である場合には、依頼元決定フラグ１８４、回答元決定フラグ１８５、合議実施フラグ１８６、依頼元引取フラグ１８７、回答元引取フラグ１８８及び他部門引取フラグ１８９が属性情報に含まれる。依頼元決定フラグ１８４は、合議を依頼する処理者の意思決定の状態を表す。回答元決定フラグ１８５は、合議の依頼に対し回答する処理者の意思決定の状態を表す。各データ項目に入力されたデータが確定データであるか未確定データであるかは、これら二つのフラグによって判別される。依頼元決定フラグ１８４と回答元決定フラグ１８５が共に“１”になったときにそのデータ項目のデータは確定状態となり、それ以外では未確定状態である。なお依頼元により決定されたデータを回答元が書き換えた場合、あるいは回答元により決定されたデータを依頼元が書き換えた場合は、それぞれ合議依頼元決定フラグ１８４あるいは合議回答元決定フラグ１８５が“０”に置き換わる。合議実施フラグ１８６は、合議が実施された場合に“１”にセットされる。合議依頼者が意思決定を行って合議依頼したデータに対し、合議回答元が値を訂正して意思決定を行った場合は、依頼元と回答元の間で合議が成立しておらず、データは確定しないが、合議は実施されたとみなして合議実施フラグ１８６が“１”にセットされる。依頼元引取フラグ１８７、回答元引取フラグ１８８、他部門引取フラグ１８９は、データ項目に設定されているデータが未確定である場合に、そのデータがそれぞれ合議依頼元、合議回答元、他部門に引き取られるときに“１”が設定される。本実施の形態においては、合議が必要とされるデータを、合議に加わらない他部門が引き取ろうとする場合には、合議実施フラグ１８６が“１”となっていることが必要であるものとする。図１１において、例えば、データ項目「納入価」に着目すると、合議フラグ１８１には“１”が設定されており、このデータ項目について合議が必要とされることが示されている。データの確定状態は、依頼元決定フラグ１８４は“１”であるが、回答元決定フラグ１８５は“０”であるので、合議依頼元による意思決定はされているが、合議回答元による意思決定がされておらず、未確定状態である。また、合議実施フラグ１８６は、“０”であるので、未だ合議は行われておらず、他部門でこのデータを引き取ることはできないことがわかる。
【００３４】
その他、属性情報として、各データ項目に対応して第１の実施の形態と同様に、先行入力フラグ１１５が設けられる。なお、掲示板データベース１８の構造として、各データ項目のデータと対応するフラグとを記憶装置上では分離して格納し、各データ項目のデータから対応するフラグへアドレスポインタによってリンクするようなデータ構造としてもよい。
【００３５】
図１２は、アクセス権限ファイル１９のデータ形式の例を示す図である。アクセス権限ファイル１９は、ユーザ別にアクセス可能なデータとそのフラグについての権限を定義するファイルである。図１２では、図１１に示すデータ項目の内、「納入価」、「納期」及びこれらデータ項目に対応する各属性情報についての定義は、図示を省略している。図中、参照のフィールドに“−”が設定されているデータ又はフラグは、参照が禁止されることを表す。書き込みのフィールドに“−”が設定されているデータ又はフラグは、書き込み又は更新ができないことを示している。書き込みのフィールドに設定される“可”は書き込み又は更新が許可されることを示し、参照のフィールドの“可”はデータを参照することが許可されることを示している。例えば、データ項目「商品名」について見ると、商品名というデータそのものについて営業担当者は参照・書き込み共に可能である。営業課長及び倉庫担当者は、データ項目「商品名」のデータを参照することはできるが、書き込みはできない。決定フラグ１８２については、営業担当者は参照・書き込みを許可されるが、営業課長及び倉庫担当者は参照のみが許可され、書き込みは許可されない。これは商品名が合議の必要ないデータ項目であり、営業担当者の裁量で決定されたデータが確定となるためである。つまり営業課長及び倉庫担当者は決定されたか否か、すなわち確定されたか否かを決定フラグ１８２で確認することはあっても、データの決定の操作は行えないことを示している。次に引取フラグ１８３については、営業担当者は書き込みできないが参照は可能である。一方、営業課長及び倉庫担当者は、引き取りフラグに対して書き込みはできるが参照はできない。これは商品名というデータ項目について営業課長及び倉庫担当者は営業担当者の決定の如何にかかわらずデータを引き取ることができることを示している。営業課長及び倉庫担当者が先行してデータを引き取ったことを示す表示は、営業担当者側の表示装置２１に表示される。営業担当者は引き取られる側なのでデータを「引き取った」ことを示す引取フラグ１８３への書き込みはできない。しかし表示画面上には、データが「引き取られた」ことが表示されるため、参照は「可」となる。一方、営業課長及び倉庫担当者は、データの引き取りを行える部署である。したがって、引取フラグ１８３への書き込みは“可”に設定される。営業課長及び倉庫担当者に対しては引き取ったことを示す表示は不要であり、参照フィールドには“−”が設定されている。また、本実施の形態では、依頼元決定フラグ１８４の書き込みができるユーザが合議依頼元であり、回答元決定フラグ１８５の書き込みができるユーザが合議回答元である。例えば「数量」というデータ項目については、営業担当者が合議依頼元、倉庫担当者が合議回答元である。なおステータス１２１及び先行入力フラグ１２３は、いずれのユーザからも参照可能であるが、書き込みはできない。また、合議フラグ１８１は、状態監視部４のプログラムが処理上必要な情報であり、ユーザが直接書き込み又は参照することがないため全てのフィールドに“−”が設定されている。
【００３６】
図１３は、サーバ１とクライアント２の間で送受信されるデータの形式を示すフォーマット図である。図１３（ａ）は、サーバ１からクライアント２に送信される掲示板データの形式を示している。各データ項目のデータには、決定フラグ１６１、確度フラグ１６２及び先行引取フラグ１６３が付加される。決定フラグ１６１は対応するデータ項目の決定フラグの状況を示すフラグであり、合議の必要ないデータ項目については決定フラグ１８２の値が格納される。合議を必要とするデータ項目については、送信先ユーザが合議依頼元か合議回答元かによってそれぞれ依頼元決定フラグ１８４又は回答元決定フラグ１８５の値が格納される。確度フラグ１６２は対応するデータ項目が確定しているか否かを示すフラグである。先行引取フラグ１６３は、対応するデータ項目が先行引取されたか否かを示すフラグである。
【００３７】
図１３（ｂ）は、クライアント２からサーバ１へ送信されるデータの形式を示している。送信されるデータは、各データ項目ごとにサーバ１から送られたか又はクライアント２で入力・更新されたデータとそれに付属する決定フラグ１６１及び引取フラグ１６４から構成される。決定フラグ１６１は、サーバから送られるデータ中の決定フラグと同じ意味を有する。クライアント２からサーバ１に送られるデータ中の決定フラグ１６１には、対応するデータ項目に対するユーザの決定の意思が反映される。例えば、あるデータ項目に関して、サーバから決定フラグ１６１に“０”が設定されて送られてきた未決定のデータに対して、ユーザによりそのデータを決定するための操作が行われると、決定フラグ１６１に“１”が設定されてサーバ１に送られる。引取フラグ１６４は、ユーザが対応するデータを引き取ったことをサーバ１に通知するために使用される。ユーザは所望のデータ項目のデータについて引取の操作をすることができ、ユーザによりデータの引き取り操作が行われると、そのデータ項目に対応する引取フラグ１６４に“１”が設定される。
【００３８】
図１４は、状態監視部４の処理の流れを示すフローチャートである。本実施の形態における状態監視部４の処理は、図１４に示すように、図８に示す第１の実施の形態における処理のステップ３２と３３の間にステップ７１から７６の処理が追加され、ステップ３６の処理がステップ７７、７８の処理と置き換えられる。ここでは、主に、本実施の形態において新たに行われる処理について以下に説明し、第１の実施の形態と重複する処理についてはその説明を省略する。状態監視部４は、クライアント２からの要求に応じて掲示板データベースから指定された掲示板を取り出すと（ステップ３１〜３２）、要求のあったユーザを識別子に基づいて認識する（ステップ７１）。この認識結果にしたがってアクセス権限ファイル１９を検索して、当該ユーザの各データ及びフラグについてのアクセス権限情報を取り出す（ステップ７２）。次に、取り出したアクセス権限情報に基づいて、ステップ３２で取り出された掲示板の中で当該ユーザが参照可能なデータ、すなわち表示可能なデータを選択する（ステップ７３）。
【００３９】
次に状態監視部４は、選択されたデータ及びフラグの中から決定フラグによる決定状況の判定を行い、クライアント２に送信する各データ項目に付加する決定フラグ１６１の値を求める。例えば、ステップ７３で選択されたあるデータ項目が合議を必要としないデータ項目である場合、決定フラグ１８２が“１”であれば、状態監視部４は送信するデータ項目に付属する決定フラグ１６１の値を“１”に設定する。一方、決定フラグ１８２が“０”であれば決定フラグ１６１の値を“０”に設定する。また、ステップ７３で選択されたあるデータ項目が合議を必要とするデータ項目である場合、状態監視部４は当該ユーザが合議依頼元であって依頼元決定フラグ１８４が“１”であれば、決定フラグ１６１に“１”を設定する。依頼元決定フラグ１８４が“０”であれば、決定フラグ１６１には“０”が設定される。同様に、当該ユーザが合議回答元であって回答元決定フラグ１８５が“１”であれば、状態監視部４は決定フラグ１６１の値を“１”に設定し、回答元決定フラグ１８５が“０”であれば決定フラグ１６１の値を“０”に設定する。さらに、当該ユーザが合議依頼元でも合議回答元でもない場合、状態監視部４は、依頼元決定フラグ１８４及び回答元決定フラグ１８５がともに“１”であれば決定フラグ１６１に“１”を設定し、それ以外の場合には決定フラグ１６１に“０”を設定する。これにより、合議を必要とするデータ項目であっても合議に関係ないユーザからみれば、このデータ項目は合議を必要としないデータ項目と同様に見える。状態監視部４は選択されたすべてのデータ項目について以上の処理を行う（ステップ７４）。
【００４０】
状態監視部４は、選択された各データ項目に付加される決定フラグの値を決定すると、合議フラグ１８１及び決定した決定フラグの値に基づいてデータの確度を判定する。確定されたデータについては送信するデータ項目に付属する確度フラグ１６２を“１”に設定し、未確定データについてはこの確度フラグ１６２を“０”に設定する。状態監視部４は選択されたすべてのデータ項目についてこの処理を行う。ここでの処理の詳細については後述する（ステップ７５）。
【００４１】
次に状態監視部４は、引取フラグ１８３、依頼元引取フラグ１８７、回答元引取フラグ１８８及び他部門引取フラグ１８９を参照してデータが先行引取されているか否かを判定する。先行引取されているデータについては送信するデータ項目に付属する先行引取フラグ１６３を“１”に設定する。状態監視部４は選択されたすべてのデータ項目についてこの処理を行う。この処理の詳細については後述する（ステップ７６）。
【００４２】
状態監視部４はステップ７３で選択されたデータ項目のデータ、及び選択されてデータ項目についてステップ７４〜７６で決定した決定フラグ１６１、確度フラグ１６２及び先行引取フラグ１６３をまとめて送信データとし、通信制御部１７を介してクライアント２へ送信する。クライアント２では、サーバ１から送られたデータを表示装置２１上に表示し、ユーザによる業務処理が行われる。クライアント２における業務処理の結果としてデータ項目、決定フラグ又は引取フラグに対する入力又は更新があったとき、入力・更新されたデータ、又はフラグは、先に説明した図１３（ｂ）に示すデータフォーマットにまとめられ、サーバ１に送られる。状態監視部４はこの入力データを受信し、処理期限前か否かのチェックを行う（ステップ３３〜３５）。
【００４３】
処理期限前であることが確認されると、状態監視部４は、クライアント２から送られてきたデータ及び決定フラグ１６１にしたがって掲示板データベース１８を更新する。状態監視部４は、アクセス権限ファイル１９に基づいて当該ユーザによる更新が許可され、かつデータ入力可能なデータ項目及びフラグを更新する。ここで、受信したデータ中の決定フラグ１６１に基づくフラグの更新処理は次の通り行われる。合議フラグ１８１が“０”であるデータ項目については、受信した決定フラグ１６１の値を決定フラグ１８２に設定する。すなわちユーザから意思決定があれば、決定フラグ１８２は“１”に設定される。合議フラグ１８１が“１”であるデータ項目について、ユーザが合議依頼元であり、元の依頼元決定フラグ１８４が“０”、決定フラグ１６１が“１”であれば、状態監視部４は依頼元決定フラグ１８４を“１”に設定する。ユーザが合議回答元であり、元の回答元決定フラグ１８５が“０”、決定フラグ１６１が“１”のときも同様に合議回答元決定フラグ１８５を“１”に設定する。この操作により依頼元決定フラグ１８４及び回答元決定フラグ１８５の両方が“１”になったときには、合議実施フラグ１８６を“１”に設定する。依頼元決定フラグ１８４が“１”であるデータ項目のデータを回答元が更新したときは、回答元決定フラグ１８５の内容にかかわらず依頼元決定フラグ１８４を“０”に変更し、合議実施フラグ１８６に“１”を設定する。回答元決定フラグ１８５が“１”であるデータ項目のデータを依頼元が更新したときは、依頼元決定フラグ１８４の内容にかかわらず回答元決定フラグ１８５を“０”に変更し、合議実施フラグ１８６を“１”にする（ステップ７７）。
【００４４】
次に、状態監視部４は、引取フラグを設定する処理を行う。合議フラグ１８１に“０”が設定されており、かつ決定フラグ１８２が“０”であるデータ項目については、受信した引取フラグ１６４の値が引取フラグ１８３に設定される。すなわち、状態監視部４はユーザから先行引取の要求があれば、引取フラグ１８３に“１”を設定する。合議フラグ１８１が“１”であるデータ項目に対しては、受信した引取フラグ１６４が“１”であるとき、ユーザが合議依頼元、合議回答元又は他部門のいずれかによって、また合議実施フラグ１８６、依頼元決定フラグ１８４、回答元決定フラグ１８５の状態にしたがって依頼元引取フラグ１８７、回答元引取フラグ１８８及び他部門引取フラグ１８９の設定が制御される（ステップ７８）。
【００４５】
以上のようにして掲示板データベース１８を更新すると、状態監視部４は、第１の実施の形態と同様にステップ３７〜ステップ４４の処理を行う。
【００４６】
図１５は、ステップ７５で行われるデータの確度判定処理の詳細なフローチャートである。状態監視部４はステップ７選択されたデータ及びフラグについて、合議フラグ１８１に“１”が設定されているか否か判定する（ステップ８１）。合議フラグ１８１が“０”場合、状態監視部４はそのデータ項目について決定フラグ１８２の値の判定を行う（ステップ８４）。決定フラグ１８２が“１”であれば、クライアント２側へ送信するデータ項目に付属する確度フラグ１６２が“１”に設定される（ステップ８５）。決定フラグ１８２が“０”である場合は送信するデータ項目に付属する確度フラグ１６２は“０”に設定される（ステップ８６）。一方、ステップ８１において合議フラグ１８１が“１”の場合、状態監視部４は、続いて、依頼元決定フラグ１８４に基づき、合議依頼元がデータを決定しているか否かを判定する（ステップ８２）。依頼元決定フラグ１８４が“０”の場合、状態監視部４は、送信するデータ項目に付属する確度フラグ１６２を“０”に設定する（ステップ８６）。依頼元決定フラグ１８４が“１”の場合、状態監視部４はさらに、回答元決定フラグに基づき合議回答元がデータを決定しているか否かを判定する（ステップ８３）。回答元決定フラグ１８５が“０”の場合、状態監視部４は送信する送信するデータ項目に付属する確度フラグ１６２を“０”に設定する（ステップ８６）。回答元決定フラグ１８５が“１”の場合は、送信するデータ項目に付属する確度フラグ１６２は“１”に設定される（ステップ８５）。
【００４７】
以上のようにして確度フラグ１６２に“１”が設定されるようなデータ項目は、そのデータが確定しているものである。このようなデータは第１の実施の形態における確定データに相当するものであり、以降、本実施の形態においても同様に、確定データと呼ぶ。また、上述した処理により確度フラグが“０”になるような状態のデータは、未確定データと呼ぶ。
【００４８】
図１６は、ステップ７６で行われるデータの先行引取判定処理の詳細なフローチャートである。状態監視部４は、選択されたデータ及びフラグについて、合議フラグ１８１の値を判定する（ステップ９１）。合議フラグ１８１が“０”場合、状態監視部４は、そのデータ項目の決定フラグ１８２の判定を行う（ステップ９２）。決定フラグ１８２が“１”の場合は、先行引取が生じないのでそのままステップ３３の処理に移る。決定フラグ１８２が“０”の場合、状態監視部４はさらに、引取フラグ１８３の判定を行う（ステップ９３）。引取フラグ１８３が“１”のであれば、状態監視部４はクライアント２へ送信するデータ項目に付属する先行引取フラグ１６３を“１”に設定した後ステップ３３に移る（ステップ９９）。引取フラグ１８３が“０”であれば、先行引取は行われていないものとしてステップ３３の処理に移る。
【００４９】
ステップ９１において合議フラグ１８１が“１”であった場合、状態監視部４は、他部門引取フラグ１８９に基づき他部門によりデータが引き取られているか否か判定する（ステップ９４）。他部門引取フラグ１８９が“１”のとき、状態監視部４は、依頼元決定フラグ１８４、及び回答元決定フラグ１８５に基づいて、合議回答元が合議依頼元からデータを引き取ったか否か、並びに、合議依頼元が合議回答元からデータを引き取ったか否かについて判定する（ステップ９５）。依頼元決定フラグ１８４と回答元決定フラグ１８５の両方が“１”の場合は、先行引取が生じないので、状態監視部４はそのままステップ３３の処理に移る。依頼元決定フラグ１８４と回答元決定フラグ１８５の両方が“１”でない場合、すなわち依頼元決定フラグ１８４と回答元決定フラグ１８５の少なくともいずれか一方が“０”に設定されている場合、状態監視部４は送信するデータ項目に付属する先行引取フラグ１６３を“１”に設定する（ステップ９９）。このように、他部門引取フラグ１８９が“１”の場合、依頼元決定フラグ１８４及び回答元決定フラグ１８５の両方に“１”が設定されていなければ、そのデータは他部門によって先行引取されたこととなる。
【００５０】
ステップ９４において、他部門引取フラグ１８９の値が“０”であった場合、状態監視部４は、ユーザが他部門か否か判定する（ステップ９６）。ユーザが他部門の場合には、先行引取でないのでそのままステップ３３の処理に移る。ユーザが他部門でなく、合議依頼元か合議回答元である場合、状態監視部４は、依頼元引取フラグ１８７に基づいて合議依頼元がデータを引き取ったか否か判定する（ステップ９７）。依頼元引取フラグ１８７が“１”の場合には、送信するデータ項目に付属する先行引取フラグ１６３に“１”が設定される（ステップ９９）。依頼元引取フラグ１８７が“０”の場合には、さらに回答元フラグ１８８に基づいて合議回答元がデータを引き取ったか否かが判断される（ステップ９８）。回答元引取フラグ１８８が“１”の場合、状態監視部４は送信するデータ項目に付属する先行引取フラグ１６３を“１”に設定し（ステップ９９）、回答元引取フラグ１８８が“０”の場合にはそのままステップ３３の処理に移る。
【００５１】
図１７は、ステップ７８で行われる引取フラグ設定処理の流れを示すフローチャートである。掲示板データベース１８において合議フラグ１８１が“１”であるデータ項目について、クライアント２から受信した対応する引取フラグ１６４が“１”であるとき、つまりクライアント２においてユーザによりデータの引き取りの操作がされたとき、状態監視部４は以下の処理を行う。まずユーザの識別を行い、ユーザが合議依頼元又は合議回答元であるか否か判定する（ステップ１０１）。判定の結果、ユーザがユーザが合議依頼元及び合議回答元のいずれでもない他部門のユーザである場合、状態監視部４は合議実施フラグ１８６の判定を行う（ステップ１０２）。本実施の形態では、「一回でも合議を行っていない合議を必要とするデータを他部門のユーザが引き取ることはできない」というルールに基づいて処理が行われる。このため、合議が実施され、合議実施フラグ１８６が“１”にならない限り他部門のユーザはそのデータを先行引取することができない。ステップ１０２において合議実施フラグ１８６が“１”でないと判定された場合は、先行引取はできないので、状態監視部４は、要求のあったクライアント２へエラーメッセージを送り処理を終える（ステップ１１０）。合議実施フラグが“１”であれば、次に、依頼元決定フラグ１８４と回答元決定フラグ１８５の判定を行う。この判定は、該当するデータの引取が、先行引き取りとなるか否かを区別するために行われる（ステップ１０３）。依頼元決定フラグ１８４と回答元決定フラグ１８５の両方が“１”の場合には、先行引取にはならないのでここでの処理は終了する。依頼元決定フラグ１８４と回答元決定フラグ１８５の両方が“１”でない場合、状態監視部４は他部門引取フラグ１８９に“１”を設定して処理を終了する（ステップ１０４）。ステップ１０１において、ユーザが合議依頼元又は合議回答元であると判定された場合は、次に、ユーザが合議依頼元であるか否かの判定を行う（ステップ１０５）。ユーザが合議依頼元である場合、回答元決定フラグ１８５の判定を行う（ステップ１０６）。回答元決定フラグ１８５が“１”、すなわちデータが決定状態にあるときは、先行引取にはならないのでそのまま処理は終了する。回答元決定フラグ１８５が“１”でない場合、すなわちデータが未決定状態にあるとき、状態監視部４は、合議回答元による決定がされないうちに合議依頼元がデータを引き取ったことを示すために、依頼元引取フラグ１８７に“１”を入れて処理を終える（ステップ１０７）。また、ステップ１０５において、ユーザが合議回答元であると判定された場合、状態監視部４は、依頼元決定フラグ１８４の判定を行う（ステップ１０８）。依頼元決定フラグ１８４が“１”、すなわちデータが決定状態にあるときは、先行引取にならないのでそのまま処理を終了する。依頼元決定フラグ１８４が“１”でない場合、すなわちデータが未決定状態にあるとき、状態監視部４は、合議依頼元による決定がされないうちに合議回答元がデータを引き取ったことを示すため、回答元引取フラグ１８８に“１”を入れて処理を終了する（ステップ１０９）。
【００５２】
以上の処理の結果、サーバ１から送られる掲示板データにしたがってクライアント２の表示装置２１に掲示板データがどのように表示されるか、以下、いくつかの例を挙げて具体的に説明する。
【００５３】
図１８は、クライアント２の表示装置２１に表示される掲示板の第１の表示例であり、主に、各データについて、担当者、あるいは管理者により意思決定がなされたか否かが画面上でどのように表されるかを説明するための図である。ユーザ入出力部２３はサーバ１から送られてきた掲示板の各データ項目についてデータの表示を行うとともに、各データ項目に付属の決定フラグ１６１にしたがって、表示されたデータに対応するラジオボタンをオン又はオフにして表示する。図において、白抜きの丸で表されるのがオフ状態のラジオボタンであり、丸の中に黒いドットが表示されたものがオン状態のラジオボタンである。各ラジオボタンは、それが対応するデータについて担当者や管理者が意思決定したか否かを表している。図１８に示す例では顧客名と商品名のすべてのデータが決定しており、これらのデータに対応するラジオボタンがオンになっている。一方、数量、納入価及び納期というデータ項目については、ラジオボタンがオフとなっており、まだ意思決定されていないことを表している。なおユーザはラジオボタンを押下することによってオフ表示をオン表示に変更でき、この結果は対応するデータ項目の決定フラグ１６１としてサーバ１へ送られる。
【００５４】
図１９は、表示装置２１に表示される掲示板の第２の表示例であり、主として、表示される各データについてその確度の確定・未確定が画面上でどのように表示されるかを説明するための図である。ユーザ入出力部２３はサーバ１から掲示板のデータを受け取ると、各データ項目に付属の確度フラグ１６２の値にしたがって各データを太字又は細字で表示装置２１に表示する。この例では、顧客名と商品名のデータが太字で表示されている。これによりユーザは、顧客名と商品名についてはデータが確定していることを認識することができる。一方、数量、納入価及び納期の各データは細字で表示されており、まだ確定していないことがわかる。
【００５５】
図２０は、表示装置２１に表示される掲示板の第３の表示例であり、主に、データの確度が画面上でどのように表示されるかを説明するための図である。ここでは、クライアント２のユーザが営業担当者である場合の表示装置２１に表示される表示画面を仮定して説明を行う。なお、顧客名及び商品名については、営業担当者の意思決定によりデータが確定し、納入価格は営業担当者が決定したデータに対して営業課長が決済することで、すなわち、合議によりデータが確定するものとする。また、数量と納期については、営業担当者と倉庫担当者の合議により確定するものとする。この例では顧客名、商品名は、太字で表示されており営業担当者により意思決定がなされ、確定していることがわかる。また、テレビの納入価及びビデオの納入価も太字で表示されており、営業担当者により意思決定がされ、営業課長により決済がなされてデータが確定していることがわかる。一方、エアコンの納入価については、ラジオボタンはオンであるが、データは細字で表示されている。したがって、営業担当者の意思決定はされているが、営業課長による決済がされておらず、未確定のデータであることがわかる。同様に、各商品の数量についても、ラジオボタンがオンで、細字で表示されているので、このクライアント２を操作する営業担当者により決定されているが、倉庫担当者による決定が未だされていないことがわかる。納期についてはデータは設定されているが、営業担当者はまだ意思決定をしていないのでラジオボタンがオフになっている。
【００５６】
図２１は、表示装置２１に表示される掲示板の第４の表示例であり、主に、引き取られたデータを表示する表示画面を説明するための図である。ここでは各データの確定状態が図２０に例示したものと同じであるものとし、このような状態で、倉庫担当者によりデータ項目が「顧客名」、「商品名」、「数量」、「納期」のデータが引き取られているものとして説明する。営業担当者の操作するクライアント２の表示装置２１には、図２１に示すような掲示板が表示される。本実施の形態では、先行して引き取られた未確定データは、通常に引き取られた確定データと区別できるように下線を付して表示される。図に示す例では、顧客名、商品名というデータ項目のデータは確定データであることから、倉庫担当者によりこれらのデータが引き取られていてもこれらのデータに下線は付されない。「数量」というデータ項目のデータについては合議の必要があり、未確定ではあるが営業担当者による意思決定はされている。また、倉庫担当者はこのデータ項目に関しては合議回答元となるため、合議依頼元である営業担当者による意思決定が行われていれば通常引取とみなされ、先行引取を意味する下線は表示されなデータ項目の“６／１０”というデータは営業担当者による意思決定がされていないので、合議回答元である倉庫担当者により引き取られたことを表すために下線が表示される。
【００５７】
以上説明した実施の形態によれば、複数の作業工程の担当者の意思決定を反映する合議の形でデータの確定をし合議の結果をユーザに通知するとともに未確定なデータを先行して引き取ったことをデータ入力したユーザに通知するので、他のユーザのとったアクションについて状況把握をしながら作業を進めることができる。なお、本実施の形態では合議回答元がただ１つの部門である場合を例に説明した。合議回答元が複数部門ある場合も上記実施の形態と同様に実現することができる。この場合には、上記実施の形態において、回答元決定フラグの判定を行う処理において、すべての合議回答元に対応する回答元決定フラグが“１”に設定されたときに合議回答元でデータが決定したものとして扱えばよい。
【００５８】
（第３の実施の形態）
第１及び第２の実施の形態では、掲示板の状態を所定のデータ項目が確定状態となったときに状態が遷移する。データ項目に対してデータが確定入力されていく形態としては次のような形態が考えられる。まず第１は、１つのデータ項目について取り得るデータが１つしかない形態である。この場合、１つの掲示板は１つのレコードで構成される。第２は、少なくとも１つのデータ項目について取り得るデータが２つ以上あるものである。この場合は、１つの掲示板が複数レコードで構成される。掲示板を構成するレコードが単一のときと複数のときとではその掲示板にデータを格納する方法も異なってくる。単一レコードの掲示板では、すべてのデータ項目に入力されたデータに対して掲示板上の作業状態が反映されるようにデータがデータベースに格納されなければならない。一方、複数レコードからなる掲示板ではデータ項目に対して部分的にしかデータが入力されていなくても、各レコードごとに掲示板の状態を遷移することができる。例えば、商品名というデータ項目内にデータとして複数の商品の名称が登録されるような掲示板の場合、このデータ項目のデータがすべて確定入力されていなくても、一つ一つのデータごとに状態を確定していくことができる。また、複数レコードからなる掲示板では、各レコードの状態の組み合わせによって状態を判定するようにすることもできる。このように、ユーザによって同じようなデータ項目でもデータの確定する形式が違ってくることが考えられる。そこで、本実施の形態では、データの確定に対する掲示板の状態の遷移に柔軟性を持たせ、実際の業務形態にあわせた柔軟な運用を行えるようにした。
【００５９】
図２２は、本発明による第３の実施の形態の業務処理システムの構成図である。本実施の形態における業務処理システムは、状態遷移ルール２７の構造、および状態監視部５により実現される機能の一部が第２の実施の形態と異なる点を除いて、基本的には、第２の実施の形態と同様の構成を有する。したがって、ここでは、第２の実施の形態と共通する部分については、第２の実施の形態の説明で用いた参照符号を流用して説明を行う。
【００６０】
図２３は、本実施の形態における状態遷移ルール２７のデータ形式を示す図である。本実施の形態における状態遷移ルール２７は、各作業工程ごとに、その作業工程の業務を行うために決定していることが必要となるデータ項目を定義している。図２３では、掲示板番号“００１”で識別される掲示板を用いて進められる業務について定義された状態遷移ルール２７を示している。なお、状態遷移ルール２７は、どの作業工程による作業に遷移することが可能であるかを示しており、次の作業工程に遷移するために必要な条件を定義している第１の実施の形態の状態遷移ルール１２及び第２の実施の形態の状態遷移ルール２０とは異なっている。図２３において、作業工程２７１には、業務における各作業工程が登録される。掲示板番号２７２には、繊維状態の定義が行われる掲示板の掲示板番号が登録される。状態定義欄２７３〜２７７は、掲示板データベース１８の各データ項目に対応しており、各作業工程において、その作業工程の業務を行うために対応するデータ項目のデータが満たさなければならない状態が設定される。“−”が設定されている状態定義欄については、対応する作業工程における処理を実施するためにそのデータ項目のデータが確定している必要がないことを示している。入力されるべきデータが複数あるデータ項目が存在する場合、作業に必要なデータ項目について、そのデータ項目の全てのデータが確定しなければならないものには“ＡＬＬ”が設定される。そのデータ項目のいずれかのデータが確定していればよい場合には、状態定義欄に“ＥＡＣＨ”が設定される。また、１つのデータしか与えられないデータ項目について、そのデータが確定している必要がある場合は、状態定義欄に“ＡＬＬ”が設定される。なお、１つのデータしか与えられないデータ項目については、複数のデータが与えられるデータ項目と区別するために、そのデータが確定していることが必要であることを示すために、例えば、“確定”などの情報を設定するようにしてもよい。図２３に示す例では、「引合」の作業工程は、一連の業務の中で最初の作業工程であり、全てのデータが未確定の状態で業務が行われるため、全てのデータ項目について状態定義欄２７３〜２７７に“−”が設定されている。また、「在庫確認」の作業工程は、顧客名（１つの掲示板は、「顧客名」に１つのデータのみが与えられるものとする）の他、いずれかの商品について、商品名とその数量確定していればよいことを定義する。したがって、顧客名に対応する状態定義欄２７３には“ＡＬＬ”が、商品名と数量に対応する状態定義欄２７４、２７５には“ＥＡＣＨ”が設定される。さらに、「価格見積」の作業工程では、納期以外のデータ項目でデータが確定している必要があることから、納期に対応する状態定義欄２７７を除く状態定義欄２７３〜２７６に“ＡＬＬ”が設定される。
【００６１】
なお、本実施の形態の状態遷移ルール２７は、作業工程の状態遷移についてそれに必要な条件を定義しているに止まっており、掲示板データベースへのデータの入力・更新の履歴を取ることができない。履歴の取得が必要であれば、先に説明した実施の形態のように、各データ項目ごとに、入力されるデータとそのデータ項目に対応する属性情報を登録できるようにすることで対応できる。あるいは、履歴取得用のファイルを別途用意するようにしてもよい。
【００６２】
本実施の形態において状態監視部５により行われる処理は、第２の実施の形態で状態監視部４が行う処理と次の２点を除くとほぼ同じである。状態遷移があったかどうかを判定するための処理（ステップ３９）において行われる判定処理が異なる。また、状態遷移ルール２７に履歴を残さないため、状態遷移ルールの更新処理（ステップ３７）は行われない。図２４に本実施の形態で状態監視部５により行われる状態遷移の判定処理のフローチャートを示す。状態監視部５は、状態遷移ルール２７を参照して、現在の作業工程の次の作業工程についての定義情報を取得する（ステップ３００）。取得した定義情報の内、“ＡＬＬ”が設定されいるデータ項目について、全てのデータが確定しているか判定する（ステップ３０１）。“ＡＬＬ”が設定されいるデータ項目について、全てのデータが確定していればさらに、定義情報として、“ＥＡＣＨ”が定義されているデータ項目について、定義情報が満足されているか判定する。具体的には、掲示板データベースのレコードの中で、状態遷移ルール２７により“ＥＡＣＨ”が設定されているデータ項目について全てのデータが決定しているレコードがあるか調べる。このようなレコードがあれば、定義情報“ＥＡＣＨ”が満足されていることになる（ステップ３０２）。定義情報“ＥＡＣＨ”についても満足されていれば、次作業工程への状態遷移が可能であるので、状態遷移があったものと判定する（ステップ３０３）。一方、ステップ３０１、またはステップ３０２において、条件を満足しないと判定された場合、状態遷移がないものと判定される（ステップ３０４）。
【００６３】
以上述べたように第３の実施の形態によれば、状態の遷移の仕方をデータ項目ごとに細かく設定することができる。これにより、各ユーザは案件毎あるいは案件に含まれるデータ項目のデータに対して、現在の作業状態をお互いに認識でき、他の作業者との連携をよりスムーズに快適に図ることができる。なお、上記実施の形態において、状態遷移期限ルールに登録されるデータ項目、及びそのデータ項目に対応する属性情報について、掲示板データベースにあるデータを用いるようにすれば、状態遷移期限ルールにこれらのデータを登録する必要をなくすことができる。この場合には、ステップ４２における処理を省略することが可能である。また、本実施の形態においては、掲示板データベースは、業務処理により入力・更新されるデータを保持するようにし、業務処理で更新されることのない合議フラグを掲示板データベースとは別に設けるようにしてもよい。
【００６４】
上記実施の形態では掲示板データベースに現在の作業工程を識別可能とするためにステータスに関する情報を持たせているが、このデータを掲示板データベースに持たせないようにすることも可能である。この場合、ステータスを知る必要があるときには、掲示板データベース内の属性情報に基づいて、各データ項目の確定状態を調べ、その結果から状態遷移ルールを参照して現在のステータスを求めればよい。また、状態を遷移させるかどうかの判定を行うためには、クライアントから送られてきたデータにより掲示板データベースを更新する前の段階で一旦ステータスを求めてそれを保持しておく。そして、ステップ３９において掲示板データベースを更新した後に求まるステータスと保持されているステータスを比較することで状態が遷移したかどうかを判定するようにすればよい。
【００６５】
【発明の効果】
以上述べたように本発明によれば、業務処理に関するすべてのデータ項目の内容が掲示板型データベースの形式で関連するすべての担当者に開放される。このため、各担当者はいつでも業務処理の進行を見ることができ、作業効率の向上に効果が大きい。
【図面の簡単な説明】
【図１】第１の実施の形態における業務処理システムの構成図である。
【図２】掲示板データベースのデータ形式の例を示す図である。
【図３】状態遷移ルールのデータ形式の例を示す図である。
【図４】状態遷移期限ルールのデータ形式の例を示す図である。
【図５】メッセージファイルのデータ形式の例を示す図である。
【図６】宛先ファイルのデータ形式の例を示す図である。
【図７】第１の実施の形態での掲示板の表示例を示す図である。
【図８】状態監視部の処理の流れを示すフローチャートである。
【図９】後工程の先行入力に関する処理の流れを示すフローチャートである。
【図１０】第２の実施の形態における業務処理システムの構成図である。
【図１１】掲示板データベースのデータ形式を示す図である。
【図１２】アクセス権限ファイルのデータ形式を示す図である。
【図１３】サーバとクライアントとの間で送受信されるデータの形式を示すフォーマット図である。
【図１４】状態監視部の処理の流れを示すフローチャートである。
【図１５】データの確度判定処理の流れを示すフローチャートである。
【図１６】データの先行引取判定処理の処理の流れを示すフローチャートである。
【図１７】引取フラグ設定処理の処理の流れを示すフローチャートである。
【図１８】表示装置に表示される掲示板データの表示例を示す図である。
【図１９】表示装置に表示される掲示板データの表示例を示す図である。
【図２０】表示装置に表示される掲示板データの表示例を示す図である。
【図２１】表示装置に表示される掲示板データの表示例を示す図である。
【図２２】第３の実施の形態における業務処理システムの構成図である。
【図２３】状態遷移ルールのデータ形式の例を示す図である。
【図２４】状態遷移の有無を判定するための処理のフローチャートである。
【図２５】業務プロセスの一例を示す業務フロー図である。
【符号の説明】
１…サーバ
２…クライアント
３、４、５…状態監視部
１１、１８…掲示板データベース
１２、２０、２７…状態遷移ルール
１３…状態遷移期限ルール
１４…メッセージファイル
１５…宛先ファイル
１６…ファイル管理部
２１…表示装置
２２…入力装置
１９…アクセス権限ファイル
７０…ネットワーク

Claims (18)

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

Images