JPH08272875A - 業務プロセスにおけるデータ回付方法 - Google Patents

Abstract

(57)【要約】 【目的】 業務プロセス上必要なデータの中に未確定部
分があったとしても、必要なデータを必要とする部門に
宛先指定操作を行うことなく伝達すること。 【構成】 複数項目のデータを入力担当の業務処理部門
から入力する際に、そのデータと共に確定度を示すパラ
メータを入力し、各業務処理部門に共通のデータベース
に格納する第１のステップと、各データ項目の入力状況
および前記パラメータと業務処理の進捗段階との関係を
定義した進捗段階定義テーブルにより、業務プロセスの
進捗段階を判定する第２のステップと、業務プロセスの
進捗段階および回付対象のデータ項目並びに回付宛先の
関係を定義した回付先定義テーブルにより、各進捗段階
において回付すべきデータ項目および回付宛先を判定
し、そのデータ項目のデータを前記データベースから引
出し、判定結果の回付宛先の業務処理部門のデータ入出
力装置に対して転送する第３のステップとを備える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、業務プロセスにおける
データ回付方法に係り、特に多くの業務処理部門あるい
は担当者が関与することで、一連の業務処理プロセスが
形成されるような業務活動においてデータ回付を行なう
のに好適なデータ回付方法に関する。

【０００２】

【従来の技術】ネットワークの拡大、オープンシステム
やダウンサイジングによるエンドユーザコンピューティ
ングの向上等にともない、企業における様々な業務活動
において、情報処理技術を利用した電子的なデータのや
り取りによる業務処理が急速に増えている。

【０００３】こうした情報処理技術を利用したデータの
やり取りにおいては、これまで紙ベースの伝票や帳票、
書類等を担当部門（あるいは担当者）間で受け渡しする
ことで、業務処理プロセス上の情報回付が行われていた
ところを、担当部門が電子的なデータとして伝票や帳票
類を作成し、その伝票や帳票単位のデータを、次に受け
取るべき担当部門との間で、オンラインネットワーク等
を利用して送受信するといった方法で実現されている。

【０００４】

【発明が解決しようとする課題】しかしながら、上記の
ような従来方法にあっては、伝票単位のまとまりでデー
タの受け渡しを行うことから、伝票上の全てのデータが
揃った時点で次の担当部門へ伝達することになる。この
ため、次の担当部門以降は、伝票上のデータが全て確定
するまで、そのデータの内容を知ることができない。

【０００５】図１５は、例えば、顧客に対し商品の提案
を行い、商談がすすむにつれ具体的に商品内容、価格、
納期等を交渉し、契約が成立したら関係各部門に、資材
調達、商品の設計や製造、在庫の引当、商品の搬入設置
などの手配を行い、商品が用意できたら顧客に納品し、
検収を終えた後、代金の請求／回収を行うという、販売
業務プロセスと、この販売業務プロセスに関与する担当
部門（あるいは担当者）の例を示すものであるが、見積
段階１０１で顧客と商談を進め、契約が成立すれば、手
配段階１０２で各部門へ手配伝票にて指示する業務プロ
セスにおいて、仮りに、見積段階１０１で商品内容のデ
ータが確定していなくても、製造部門１０３では未確定
情報として商品のデータだけは早く知りたいといった場
合がある。

【０００６】しかし、従来では、伝票上の全てのデータ
が揃った時点で次の担当部門へ伝達するという方法をと
っているため、未確定のデータは知ることができないと
いう問題がある。

【０００７】また、業務処理上、どのデータから決まっ
ていくかは、必ずしも一意ではないため、担当部門間の
データ伝達経路と、その時必要なデータは必ずしも一意
ではなくなる。例えば、見積段階１０１で商品内容の商
談が先に進めば、商品の見積りを行う担当部門へ先に必
要データを伝達する。逆に、納期の商談が先に進めば、
納期見積を行う担当部門へ先に必要データを伝達するこ
とになる。

【０００８】しかし、従来方法では、データ送信側の担
当部門が、その都度、受け手の担当部門の宛先と送信内
容を指定して送信処理を行うことになるため、担当部門
の作業負担がかかるとともに、情報伝達の時間的なロス
が生じるという問題がある。

【０００９】さらに、従来方法では、業務プロセスを通
じて、何種類もの伝票を作成し、伝票単位のまとまりで
担当部門間でのデータの受け渡しを行うことから、顧客
名や商品名などの同じデータを異なる伝票に何度も入力
する必要が出てくるという問題がある。

【００１０】本発明の第１の目的は、業務プロセス上必
要なデータの中に未確定部分があったとしても、必要な
データを必要とする業務処理部門（担当部門あるいは担
当者）に宛先指定操作を行うことなく伝達することがで
き、さらに共通のデータの重複入力操作を不要にするこ
とができる業務プロセスにおけるデータ回付方法を提供
することにある。

【００１１】本発明の第２の目的は、各業務処理部門で
入力されたデータを各業務処理部門で自由に入手するこ
とができる業務プロセスにおけるデータ回付方法を提供
することにある。

【００１２】

【課題を解決するするための手段】本発明は、上記第１
の目的を達成するために、基本的には、回付対象となる
複数項目のデータを入力担当の業務処理部門のデータ入
出力装置から入力する際に、そのデータと共に確定度を
示すパラメータを入力し、各業務処理部門に共通のデー
タベースに格納する第１のステップと、各データ項目の
入力状況および前記パラメータを含む判定条件と業務処
理の進捗段階との関係を定義した進捗段階定義テーブル
により、前記データベース内のデータを随時調査し、業
務プロセスの進捗段階を判定する第２のステップと、業
務プロセスの進捗段階および回付対象のデータ項目並び
に回付宛先の関係を定義した回付先定義テーブルによ
り、前記第２のステップで判定した進捗段階において回
付すべきデータ項目および回付宛先を判定し、そのデー
タ項目のデータを前記データベースから引出し、判定結
果の回付宛先の業務処理部門のデータ入出力装置に対し
て転送する第３のステップとを備えることを特徴とす
る。

【００１３】また、第２の目的を達成するために、前記
進捗段階定義テーブルおよび回付先定義テーブルを、各
業務処理部門に共通の定義と各業務処理部門に固有の定
義を設定可能にしたことを特徴とする。

【００１４】

【作用】上記手段によれば、対象とする業務プロセスの
中で、各業務処理部門（担当部門あるいは担当者）が業
務遂行上共通に必要となる複数項目のデータを入力する
際に、そのデータの確定度を示すパラメータを付加して
入力させ、これを各業務処理部門共通のデータベースに
格納させる。

【００１５】このデータベースに格納された複数項目の
データは、進捗段階定義テーブルによって随時調査さ
れ、業務プロセスの進捗段階が判定される。

【００１６】次に、回付先定義テーブルにより、第２の
ステップで判定した進捗段階において回付すべきデータ
項目および回付宛先が判定され、そのデータ項目のデー
タがデータベースから引出され、判定結果の回付宛先の
業務処理部門のデータ入出力装置に対して転送される。

【００１７】従って、例えばＡ部門からＢ部門に伝達す
るデータがａ１，ａ２，ａ３の３項目であったと仮定し
た時、このうちａ１，ａ２が入力されたら進捗段階が１
段階進むように進捗段階定義テーブルに定義し、さらに
その進捗段階においてａ１，ａ２のデータ項目のデータ
をＢ部門に送信するように定義しておくと、ａ３のデー
タ項目は未確定あるいは未入力であっても、ａ１，ａ２
のデータ項目のデータだけが先行してＢ部門に送信され
ることになる。

【００１８】これによって、業務プロセス上必要なデー
タの中に未確定部分があったとしても、必要なデータを
必要とする業務処理部門（担当部門あるいは担当者）に
伝達することができる。また、データを受信した業務処
理部門では、受信項目の内容から業務プロセスの進捗状
況を知ることができる。

【００１９】この場合、宛先は回付先テーブルに定義さ
れているため、送受信に関する宛先指定操作も不要にな
る。

【００２０】さらに、各業務処理部門で共通に使用する
顧客名等のデータは、業務プロセス中のいずれかの段階
で入力されて共通のデータベースに格納されるため、複
数の段階で重複して入力する必要がなくなる。

【００２１】また、進捗段階定義テーブルおよび回付先
定義テーブルに、各業務処理部門に共通の定義の他に、
各業務処理部門に固有の定義を設定しておくと、この固
有の定義に従って必要なデータが該当する業務処理部門
に送信される。

【００２２】これによって、各業務処理部門に固有の定
義を設定することにより、業務プロセス中で入力された
データのうち必要なデータを各業務処理部門で自由に入
手することができる。

【００２３】なお、定義されたデータ項目の他に、進捗
段階を示すデータを付加して送信するようにすれば、受
信側では、受信データ項目の内容を判断することなく、
進捗段階を直ちに把握することができる。

【００２４】

【実施例】以下、本発明の一実施例を図面により詳細に
説明する。

【００２５】図１は、本発明のデータ回付方法を適用し
たデータ回付システムの一実施例を示すブロック図であ
り、大別すると、登録設定ブロック２００、共通データ
ベース（以下、ＤＢ）２１０、制御ブロック２２０、入
出力ブロック２３０から構成されている。

【００２６】登録設定ブロック２００は、業務プロセス
の進捗段階（ステータス）を定義するステータス定義テ
ーブルや回付宛先を定義する宛先テーブルの定義データ
を設定するものであり、ステータス設定ブロック２０
１、データテーブル格納データベース（以下、データテ
ーブル格納ＤＢ）２０２、ビュー項目／宛先設定ブロッ
ク２０３とから構成されている。

【００２７】ステータス設定ブロック２０１は、業務プ
ロセスの進捗段階を定義するステータス定義テーブルの
定義データを設定するもので、定義データの設定に際
し、まず入出力項目として共通ＤＢ２１０に設定されて
いるデータ項目と同一のデータ項目をデータテーブル格
納ＤＢ２０２から読込み、登録設定権限を有する担当部
門の入出力装置２３１ａからステータス項目、データ項
目とそのデータ値の確定度を示すパラメータの組合せに
よるステータスの定義データが入力されると、その入力
されたステータス項目の定義内容をデータテーブル格納
ＤＢ２０２に格納する。

【００２８】ビュー項目／宛先設定ブロック２０３は、
回付宛先を定義する宛先テーブルの定義データを設定す
るものであり、定義データの設定に際し、共通ＤＢ２１
０に設定されているものと同一のデータ項目をデータテ
ーブル格納ＤＢ２０２から読込み、登録設定権限を有す
る担当部門の入出力装置２３１ａから各進捗段階でデー
タ回付が必要となる担当部門の宛先と、ビュー項目（担
当部門が必要とするデータ項目群）を示す定義データが
入力されると、その入力されたビュー項目と宛先の内容
をデータテーブル格納ＤＢ２０２に格納する。

【００２９】一方、共通ＤＢ２１０は、対象とする業務
プロセスの中で、各担当部門（あるいは担当者）が業務
遂行上共通に必要となる複数項目のデータと、そのデー
タの確定度を示すパラメータとを格納するもので、各担
当部門毎のデータは入出力ブロック２３０の各部門に対
応した入出力装置２３１ａ〜２３１ｎから入力される。

【００３０】制御ブロック２２０は、業務プロセスの現
在の進捗段階と、その進捗段階に応じたデータの回付先
を判定し、その判定結果の宛先の入出力装置２３１ａ〜
２３１ｎに必要なデータを共通ＤＢ２１０から引出して
回付するものであり、ステータス判断ブロック２２１と
データ回付ブロック２２とで構成されている。

【００３１】ステータス判断ブロック２２１は、共通Ｄ
Ｂ２１０に格納されているデータと、データテーブル格
納ＤＢ２０２に格納されているステータスの定義内容を
比較し、現在の業務プロセスの進捗段階を判定する。

【００３２】また、データ回付ブロック２２２は、ステ
ータス判断ブロック２２１が判断した現在の進捗段階を
基に、データテーブル格納ＤＢ２０２に格納されている
ビュー項目と宛先の内容を参照し、ビュー項目として必
要なデータ項目のデータを共通ＤＢ２１０から読み込
み、設定されている宛先の入出力装置２３１ａ〜２３１
ｎに回付する。

【００３３】図２は、業務プロセス上のデータが各担当
部門に回付される過程の概要を示す説明図であり、入力
担当部門において入力すべきデータ２４１〜２４３に
は、パラメータとして確定度２４５〜２４７が付加され
て入力される。

【００３４】このデータ２４１〜２４３および確定度２
４５〜２４７は、ステータス定義テーブル２４８の定義
データと比較される。これによって、現在の進捗段階、
すなわちステータス２４９が判定される。

【００３５】この判定結果は宛先定義テーブル２５０に
伝達され、ここで現在のステータス２４９において回付
すべきデータ項目および回付宛先が判定される。そし
て、その判定結果の宛先２５１，２５２に対し、必要な
データ２５３，２５４が送信される。

【００３６】図３は、共通ＤＢ２１０の中のデータ格納
フレームの構造を示す図であり、データ格納フレームの
中には、対象とする業務プロセスを通じて、各担当部門
共通に業務処理の進捗状況を一括管理するためのキー項
目３０１の領域が設けられている。本実施例の場合は、
販売業務を通じて１顧客からの１注文に関する全てのデ
ータを１組として扱い、この１組のデータを一括管理す
るためのキー項目３０１として「注文Ｎｏ」を設定して
いる。

【００３７】このキー項目３０１を最上位キーとし、業
務プロセスを通じて業務処理上、関与する担当部門間で
共通に必要となるデータ項目３０２に、それぞれのデー
タ値３０３と、データ値の確定度を表すパラメータ３０
４（図４参照）を格納する領域が設けられ、各領域に各
担当部門が必要なデータ値３０３およびパラメータ３０
４を格納するようになっている。

【００３８】パラメータ３０４は、図４に示すように、
「未入力」３０４１、「未確定」３０４２、「確定」３
０４３の３種類が用意され、それぞれ「未入力」３０４
１＝００、「未確定」３０４２＝０１、「確定」３０４
３＝１１のコードが割り当てられている。

【００３９】ここで、「未入力」３０４１は、データ値
が未入力であることを示し、「未確定」３０４２はデー
タ値自体は入力されいるが、担当部門が業務処理上ある
いは顧客との交渉の進み具合等の理由で、予定情報とし
て入力したデータ値であることを示すものである。「確
定」３０４３は、データ値が確定情報であることを示す
ものである。

【００４０】業務プロセスにおける入力担当部門は、こ
のパラメータ３０４を必ずしも未入力３０４１→未確定
３０４２→確定３０４３の順番に入力する必要はなく、
未入力３０４１から次に確定３０４３という順で入力す
ることも可能である。これは、実際の業務活動の中でデ
ータ値は、必ずしも未入力３０４１→未確定３０４２→
確定３０４３の順を踏んで決まるとは限らないからであ
る。

【００４１】次に、図５、図６、図７、図８、図９を用
いて、ステータス設定ブロック２０１におけるステータ
ス定義内容およびその設定処理について説明する。

【００４２】図５は、データテーブル格納ＤＢ２０２内
に形成されるステータス定義テーブル２４８の構成図で
あり、標準ステータス８０５と各担当部門が固有に設定
するユーザ定義ステータス８０６とが設けられ、図の横
軸方向（列方向）には複数のデータ項目の確定度等を用
いたステータスの判定条件を設定するように構成されて
いる。

【００４３】標準ステータス８０５は、この例では、
「引合有り」、「見積開始」、「予約手配」、「確定手
配」、「売掛計上」、「売上計上」といった業務プロセ
スの進捗段階を示す内容が設定されている。

【００４４】また、ユーザ定義ステータス８０６として
は、「見積中ａ」、「見積中ｂ」といった標準ステータ
スとは別の進捗段階を示す内容が設定されている。

【００４５】図６は、各担当部門間に共通に設定する標
準ステータス８０５の定義と登録に係る処理を示すフロ
ーチャートである。

【００４６】標準ステータス８０５は、各担当部門共通
に係るため、業務活動全般の内容に応じて所定のタイミ
ングで定義と登録の処理を行う。例えば、システムの立
ち上げ時、業務部門の組織変更時等のタイミングで定義
と登録の処理を行う。

【００４７】標準ステータス８０５を定義する場合、ま
ず、登録設定権限を有する業務部門の入出力装置（例え
ば２３１ａ）において標準ステータス８０５の「引合有
り」などの各項目を入力し、図７に示すようなステータ
ス項目テーブル７００を作成する（ステップ５０１）。

【００４８】この場合のステータス項目は、最終的に作
成しようとしている図５の項目と一致させる。

【００４９】次に、図８に示すように、データテーブル
格納ＤＢ２０２内のデータ項テーブル８００に予め設定
されている「注文Ｎｏ」等のデータ項目を読み込む（ス
テップ５０２）。

【００５０】このデータ項テーブル８００に設定されて
いるデータ項目は、共通ＤＢ２１０に担当部門が入出力
するデータ項目と同一のものである。これらのステータ
ス項目及びデータ項目を軸としてステータス定義テーブ
ル２４８のマトリクスを作成し、入出力装置２３１ａの
画面上に表示する（ステップ５０３）。

【００５１】そこで、画面上に表示されたステータス定
義テーブル２４８のマトリクスを用い、「引合有り」、
「見積開始」、「予約手配」、「確定手配」、「売掛計
上」、「売上計上」といった業務プロセスの進捗段階を
規定するデータ項目に、データ値の比較条件８０１、あ
るいはデータ値の確定度を表すパラメータ８０７、ある
いは両者の複合条件８０２から成る判定条件を入力し、
ステータスの定義を行なう（ステップ５０４）。

【００５２】複合条件８０２の例としては、「客先納
期」が確定し、且つその値が現在日付を越えている場合
といったものである。

【００５３】図５において、例えば、「注文Ｎｏ」が確
定、「顧客名」が確定、「商品内容」が未確定となった
段階で「見積開始」のステータス８０３となることを意
味する。

【００５４】また、「注文Ｎｏ」が確定、「取引価格」
が２００,０００円以上の場合、「見積中ａ」のステー
タス８０４となることを意味する。

【００５５】また、条件を設定しない空白部分は、ステ
ータスの判定条件には関与しないことを意味する。

【００５６】次に、ステータス項目の追加、変更、また
は削除があるかどうかを担当者に問い合わせ（ステップ
５０５）、追加、変更、または削除がある場合は、画面
上のマトリクスのステータス項目の欄に対して追加、変
更、削除の操作を行わせ、その操作に応じてステータス
項目の追加、変更、削除を行う（ステップ５０６）。

【００５７】そして、表示マトリクスとステータス定義
テーブル２４８の更新を行なう（ステップ５０７）。そ
して、ステップ５０３から同様の処理を繰り返す。

【００５８】全てのステータス項目の判定条件の定義を
終了したら（ステップ５０８）、ステータス項目テーブ
ル７００およびステータス定義テーブル２４８を、デー
タテーブル格納ＤＢ２０２へ格納し、登録する（ステッ
プ５０９）。

【００５９】図９は、標準ステータス８０５とは別に、
各担当部門がそれぞれ独自に使用するユーザ定義ステー
タス８０６を設定し登録する処理のフローチャートであ
る。

【００６０】この処理は、標準ステータス８０５とは独
立して、各担当部門がそれぞれの担当業務の内容、状況
に応じて、自部門の入出力装置２３１ａ〜２３１ｎを使
用して随時設定する際に起動される。

【００６１】まず、データテーブル格納ＤＢ２０２から
ステータス項目テーブル７００およびステータス定義テ
ーブル２４８を読み込み、自部門の入出力装置２３１ｘ
（ｘ＝ａ〜ｎのいずれか）の画面上に表示する（ステッ
プ９０１）。

【００６２】その表示状態でステータス項目テーブル７
００に対し、「見積中ａ」７１１、「見積中ａ」７１２
等の担当部門別定義ステータス項目を入力し、ステータ
ス項目テーブル７００を更新する（ステップ９０２）。

【００６３】以降、標準ステータス８０５の定義および
判定条件を設定する場合と同様の処理をステップ９０３
〜９０９で行う。

【００６４】なお、このステップ９０３〜９０９の処理
は、図５のステップ５０３〜５０９と同様であるので、
その説明は省略する。

【００６５】なお、標準ステータス８０５とユーザ定義
ステータス８０６は、設定、登録処理の頻度、タイミン
グが独立しているので、ステップ９０４にてステータス
定義テーブル２４８を、標準ステータス８０５の定義領
域とユーザ定義ステータス８０６の定義領域に分割し、
両者を区別して定義できるようにしている。

【００６６】次に図１０、図１１を参照し、ビュー項目
／宛先設定ブロック２０３におけるビュー項目及び宛先
の定義と登録に係わる処理について説明する。

【００６７】図１０は、所定のステータス（進捗段階）
に達した時点で、データの回付が必要な担当部門の宛先
と、その担当部門が必要としているデータのビュー項目
を設定し登録する処理のフローチャートであり、この処
理はステータス設定ブロック２３０の処理に引き続き行
われる。

【００６８】まず、データテーブル格納ＤＢ２０２から
データ項目テーブル８００およびステータス項目テーブ
ル７００を読み込み（ステップ１００１）、図１１に示
すようなビュー項目／宛先定義テーブル１１００のマト
リクスを作成し、設定権限を有する入出力装置２３１ａ
の画面上に表示する（ステップ１００２）。なお、図２
の宛先定義テーブル２５０は、ビュー項目／宛先定義テ
ーブル１１００と同じものである。

【００６９】そして、画面上で各ステータス項目に対す
るデータ回付先の担当部門の宛先ＩＤコード１１０１を
入力する（ステップ１００３）。次に、回付するデータ
項目を指定する印１１０２を入力することにより、回付
する情報として必要なビュー項目の設定を行う（ステッ
プ１００４）。

【００７０】この場合、同一ステータス項目で他に回付
する宛先があれば（ステップ１００５）、ステップ１１
０３、１１０４を繰り返す。

【００７１】次に、ステータス項目テーブル７００に登
録されている全てのステータス項目について設定が終了
したならば（ステップ１００６）、データ項目テーブル
８００、ステータス項目テーブル７００、ビュー項目／
宛先定義テーブル１１００をデータテーブル格納ＤＢ２
０２に格納し、登録する（ステップ１００７）。

【００７２】例えば、図１１においては、標準ステータ
ス８０５が「予約手配」８０８の段階に達した場合は、
「注文Ｎｏ」、「顧客名」、「商品内容」というデータ
項目のデータを宛先ＩＤ＝０１２０の担当部門に回付
し、さらに宛先ＩＤ＝０１４０の担当部門には「注文Ｎ
ｏ」、「取引価格」を回付することを意味している。

【００７３】以上のようにして、登録設定ブロック２０
０において、データテーブル格納ＤＢ２０２に対し、予
めステータス定義及びビュー項目／宛先の定義を行なっ
ておく。

【００７４】この状態で、実際に注文が発生し、業務プ
ロセス上の業務処理がスタートしたならば、共通ＤＢ２
１０の中にキー項目３０１が注文の発生順に採番され、
このキー項目３０１毎に、データ項目３０２のデータ値
３０３と、そのデータ値３０３の確定度を表すパラメー
タ３０４を格納する領域が確保される。

【００７５】各担当部門は、自部門の入出力装置２３１
ｎより、担当するデータ項目３０２のデータ値３０３と
そのパラメータ３０４を、キー項目３０１毎に、判った
時点で随時入力し、共通ＤＢ２１０に格納する操作を行
う。

【００７６】次に、図１２、図１３を用いてステータス
判断ブロック２２１の処理を説明する。なお、このブロ
ックの処理は全て制御ブロック２２０が行う。

【００７７】まず、所定のステータス監視タイミングに
なったか否かを判定し（ステップ１２０１）、所定のス
テータス監視タイミングになったならば（ステップ１２
０１）、共通ＤＢ２１０から１つの「注文Ｎｏ」のデー
タ項目３０２のデータ値３０３とパラメータ３０４を全
て読み込む（ステップ１２０２）。

【００７８】この場合、ステータス監視タイミングは、
業務内容に応じて、各担当部門共通に同じタイミング
で、例えば６時間ごとに１回、１時間ごとに１回等と決
めればよい。

【００７９】次に、読み込んだ「注文Ｎｏ」のデータ項
目３０２のデータ値３０３とパラメータ３０４と、デー
タテーブル格納ＤＢ２０２に登録されているステータス
定義テーブル２４８の定義内容とを比較し、定義されて
いるステータス（進捗段階）のどの段階に達しているか
否かを判断する（ステップ１２０３）。該当するステー
タスがない場合は（ステップ１２０４）、次の「注文Ｎ
ｏ」を検索し（ステップ１２０５）、さらにまだステー
タス判断していない「注文Ｎｏ」があれば（ステップ１
２０６）、ステップ１２０２から処理を繰り返す。

【００８０】全ての「注文Ｎｏ」についてステータスの
判断が終了したならば（ステップ１２０６）、次のステ
ータス監視のタイミング待ちになる。

【００８１】ステップ１２０４で、該当するステータス
がある場合は、次のデータ回付ブロック２２２の処理へ
移る。

【００８２】ここで、ステップ１２０３におけるデータ
項目３０２毎のパラメータ３０４についての比較基準を
図１３に示す。

【００８３】まず、ステータス定義テーブル２４８にパ
ラメータ８０７が設定されていない場合は、共通ＤＢ２
１０から読み込んだデータ値のパラメータ３０４が「未
入力」３０４１または「未確定」３０４２または「確
定」３０４３のいずれでも一致すると判断する（基準１
３０１）。

【００８４】ステータス定義テーブル２４８に設定され
ているパラメータ８０７が「未確定」３０４２の場合
は、共通ＤＢ２１０から読み込んだデータ値のパラメー
タ３０４が「未確定」３０４２または「確定」３０４３
のいずれでも一致すると判断する（基準１３０２）。

【００８５】また、ステータス定義テーブル２４８に設
定されているパラメータ８０７が「確定」３０４３の場
合は、共通ＤＢ２１０から読み込んだデータ値のパラメ
ータ３０４が「確定」３０４３４０３のとき、一致する
と判断する（基準１３０３）。

【００８６】次に、図１４を用いてデータ回付ブロック
２２２の処理を説明する。

【００８７】まず、「注文Ｎｏ」毎に、一致したステー
タス項目とデータ項目３０２のデータ値３０３、並びに
パラメータ３０４をステータス判断ブロック２２１から
受け取る（ステップ１４０１）。

【００８８】一致したステータス項目により、データテ
ーブル格納ＤＢ２０２に登録されているビュー項目／宛
先設定テーブル１１００を参照し、当該ステータス項目
に対応する宛先ＩＤコード１１０１と、その宛先へ回付
するビュー項目を判別する（ステップ１４０３）。

【００８９】次に、宛先ＩＤコード１１０１の回付先の
入出力装置２３１ｘ（ｘ＝ａ〜ｎのいずれか）に対し、
データの回付が開始されることを通知するためにアラー
ム情報を送る（ステップ１４０３）。アラーム情報とし
ては、ビュー項目の一部、例えば「注文Ｎｏ」とステー
タス項目、またはデータ回付が発生したことを伝えるメ
ッセージ等を用いる。

【００９０】これに対し、入出力装置２３１ｎからアラ
ーム情報を認識した担当者は、入出力装置２３１ｘ（ｘ
＝ａ〜ｎのいずれか）から回付データ（注文Ｎｏ、ステ
ータス項目、ビュー項目とそのデータ値、パラメータ）
の受り取り命令を入力し（ステップ１４０４）、この回
付データを入出力装置２３１ｘ（ｘ＝ａ〜ｎのいずれ
か）に取り込ませ、表示部に表示させる（ステップ１４
０５）。

【００９１】これにより、各進捗段階におけるデータが
必要とする回付先に回付される。

【００９２】詳しくは、データの入力状況あるいは確定
度が複数のステータス項目で定義されるいずれのステー
タス項目に該当するかを判定し、その判定結果のステー
タス項目においてデータの回付を必要としている宛先と
データ項目をビュー項目／宛先定義テーブル１１００の
定義に従い判定し、その判定結果の宛先に必要なデータ
を回付する。

【００９３】従って、本実施例によれば、例えばＡ部門
からＢ部門に伝達するデータがａ１，ａ２，ａ３の３項
目であったと仮定した時、このうちａ１，ａ２が入力さ
れたらステータスが１段階進むようにステータス定義テ
ーブル２４８に定義し、さらにそのステータスにおいて
ａ１，ａ２のデータ項目のデータをＢ部門に送信するよ
うに定義しておくと、ａ３のデータ項目は未確定あるい
は未入力であっても、ａ１，ａ２のデータ項目のデータ
だけが先行してＢ部門に送信されることになる。

【００９４】これによって、業務プロセス上必要なデー
タの中に未確定部分があったとしても、必要なデータを
必要とする業務処理部門（担当部門あるいは担当者）に
伝達することができる。すなわち、先行の業務処理部門
で入力すべきデータが全部揃わない段階であっても、一
部のデータを後続の業務処理部門に先行して伝達するこ
とができる。

【００９５】また、データを受信した業務処理部門で
は、受信項目の内容から業務プロセスの進捗状況を即座
に知ることができ、次の進捗段階に備えた準備作業を開
始することにより、業務プロセスの効率化を促進でき
る。

【００９６】また、業務プロセスの進捗段階の変化に応
じて即座に必要なデータが必要な宛先に回付されるとい
うことは、有効なデータの無駄な滞留時間がなくなるこ
とを意味し、進捗管理の上で極めて有益なものとなる。

【００９７】この場合、宛先はビュー項目／宛先定義テ
ーブル１１００に定義されているため、送受信に関する
宛先指定操作も不要になる。

【００９８】さらに、各業務処理部門で共通に使用する
顧客名等のデータは、業務プロセス中のいずれかの業務
処理部門で入力されるため、複数の業務処理部門で重複
して入力する必要がなくなる。

【００９９】また、ステータス定義テーブル２４８およ
びビュー項目／宛先定義テーブル１１００に、各業務処
理部門に共通の標準ステータス８０５の他に、各業務処
理部門に固有のユーザ定義ステータス８０６を設定して
おくと、この固有のユーザ定義ステータス８０６に従っ
て必要なデータが該当する業務処理部門に送信される。

【０１００】これによって、各業務処理部門に固有の定
義を設定することにより、各業務処理部門で入力された
データのうち必要なデータを各業務処理部門で自由に入
手することができる。

【０１０１】例えば、図１１の「予約手配」と「確定手
配」との間をさらに細かく区分し、その間の進捗状況に
応じたデータを回付してもらいたい場合、ステータス定
義テーブル２４８のユーザ定義ステータス８０６にその
ことを定義し、かつビュー項目／宛先定義テーブル１１
００に同じユーザ定義ステータスを設定し、回付データ
項目を設定すればよい。すなわち、業務プロセス中で使
用されるデータのうち必要とするデータを自由に入手す
ることができる。

【０１０２】さらに、ステータス定義テーブル２４８の
定義マトリクスおよびビュー項目／宛先定義テーブル１
１００の定義マトリクスを入出力装置の画面に表示し、
この画面上に必要な定義データを入力することにより、
ステータス定義テーブル２４８の定義マトリクスおよび
ビュー項目／宛先定義テーブル１１００を作成するよう
にしているため、ステータス定義およびビュー項目／宛
先定義を極めて容易に行い、しかも変更も容易に行うこ
とができ、業務プロセス中の組織変更等に柔軟に対処す
ることができる。

【０１０３】なお、上述の実施例において、データの確
定度を示すパラメータとして「未入力」３０４１、「未
確定」３０４２、「確定」３０４３の３段階のパラメー
タを例示しているが、これに限定されるものではなく業
務内容によっては、更に多段階の設定も可能である。

【０１０４】また、ステータス定義テーブル２４８にお
いて、標準ステータスとユーザ定義ステータスの区別を
容易にするために、標準ステータスの設定領域とユーザ
定義ステータスの設定に分割して設定している例を示し
ているが、これに限定されるものではなく、入力した時
間順に設定することもできる。

【０１０５】また、ステータス判断処理では、ステップ
１２０２で１つの「注文Ｎｏ」毎にデータを読み込んで
いるが、これに限定されるものではなく、一度に全ての
「注文Ｎｏ」分のデータを読み込む方法をとってもよ
い。

【０１０６】また、図１３で示したパラメータの比較基
準は、これに限定されるものではなく、設定されたパラ
メータの数と意味内容によって決めることができる。

【０１０７】また、ステータス判断ブロック２２１へ共
通ＤＢ２１０の内容を一旦取り込み、データ回付ブロッ
ク２２２を介して各担当部門がデータを受け取る例を示
しているが、これに限定されるものではなく、ステータ
ス判断ブロック２２１は共通ＤＢ２１０の内容を参照
し、データ回付ブロック２２２からのアラーム情報を担
当部門が受けた後、その担当部門が共通ＤＢ２１０から
データを取り込むようにしてもよい。

【０１０８】

【発明の効果】以上述べたように本発明によれば、業務
プロセス上必要なデータの中に未確定部分があったとし
ても、必要なデータを必要とする業務処理部門（担当部
門あるいは担当者）に伝達することができる。すなわ
ち、先行の業務処理部門で入力すべきデータが全部揃わ
ない段階であっても、一部のデータを後続の業務処理部
門に先行して伝達することができる。

【０１０９】また、データを受信した業務処理部門で
は、受信項目の内容から業務プロセスの進捗状況を即座
に知ることができ、次の進捗段階に備えた準備作業を開
始することにより、業務プロセスの効率化を促進でき
る。

【０１１０】また、業務プロセスの進捗段階の変化に応
じて即座に必要なデータが必要な宛先に回付されるとい
うことは、有効なデータの無駄な滞留時間がなくなるこ
とを意味するので、進捗管理の上で極めて有益なものと
なり、業務プロセスの効率化を促進できる。

【０１１１】さらに、データは回付先定義テーブルの定
義内容に従って回付されるため、送受信に関する宛先指
定操作も不要になる。

【０１１２】さらに、各業務処理部門で共通に使用する
顧客名等のデータは、業務プロセス中のいずれかの業務
処理部門で入力されるため、複数の業務処理部門で重複
して入力する必要がなくなる。

【０１１３】また、各業務処理部門に共通の標準ステー
タスの他に、各業務処理部門に固有のユーザ定義ステー
タスを設定しておくと、この固有のユーザ定義ステータ
スに従って必要なデータが該当する業務処理部門に送信
されるので、各業務処理部門で入力されたデータのうち
必要なデータを各業務処理部門で自由に入手することが
できる。

【０１１４】さらに、進捗段階定義マトリクスおよび回
付先定義マトリクスをデータ入出力装置の画面に表示
し、その表示画面上で必要な定義データを入力すること
により、進捗段階定義テーブルおよび回付先定義テーブ
ルを作成するようにしているため、進捗段階定義および
回付先定義を極めて容易に行い、しかも変更も容易に行
うことができ、業務プロセス中の組織変更等に柔軟に対
処することができる。

【図面の簡単な説明】

【図１】本発明のデータ回付方法を適用したシステムの
一実施例を示すブロック図である。

【図２】本発明によるデータの回付過程を示す説明図で
ある。

【図３】共通ＤＢの中のデータ格納フレームの構成図で
ある。

【図４】データの確定度を表すパラメータの例を示す説
明図である。

【図５】ステータス定義テーブルの構成図である。

【図６】ステータス定義テーブルにおける標準ステータ
スの設定・登録処理を示すフローチャートである。

【図７】ステータス項目テーブルの構成図である。

【図８】データ項目テーブルの構成図である。

【図９】ステータス定義テーブルにおけるユーザー定義
ステータスの設定・登録処理を示すフローチャートであ
る。

【図１０】ビュー項目／宛先定義テーブルの設定・登録
処理を示すフローチャートである。

【図１１】ビュー項目／宛先定義テーブルの構成図であ
る。

【図１２】ステータス判断処理のフローチャートであ
る。

【図１３】パラメータの比較基準の一例を示す説明図で
ある。

【図１４】データ回付処理のフローチャートである。

【図１５】販売業務プロセスと関与する担当部門の一例
を示す説明図である。

【符号の説明】

２００…設定登録ブロック、２０１…ステータス設定ブ
ロック、２０２…データ格納ＤＢ、２０３…ビュー項目
／宛先設定ブロック、２１０…共通ＤＢ、２２０…制御
ブロック、２２１…ステータス判断ブロック、２２２…
データ回付ブロック、２３０…入出力ブロック、２３１
ａ〜２３１ｎ…入出力装置、２４８…ステータス定義テ
ーブル、３０２…データ項目、３０３…データ値、８０
５…標準ステータス、８０６…ユーザ定義ステータス、
３０４…パラメータ、１１００…ビュー項目／宛先定義
テーブル、１１０１…宛先ＩＤコード。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 板橋 正文 神奈川県川崎市幸区鹿島田890番地の12 株式会社日立製作所情報システム事業部内 (72)発明者 吉本 美津子 神奈川県川崎市幸区鹿島田890番地の12 株式会社日立製作所情報システム事業部内

Claims (5)

【特許請求の範囲】
1. 【請求項１】 一連の業務プロセスにおける複数の業務
   処理部門に配置された複数のデータ入出力装置に対し、
   各業務処理部門で必要となるデータをネットワークを介
   して回付するデータ回付方法であって、 回付対象となる複数項目のデータを入力担当の業務処理
   部門のデータ入出力装置から入力する際に、そのデータ
   と共に確定度を示すパラメータを入力し、各業務処理部
   門に共通のデータベースに格納する第１のステップと、 各データ項目の入力状況および前記パラメータを含む判
   定条件と業務処理の進捗段階との関係を定義した進捗段
   階定義テーブルにより、前記データベース内のデータを
   随時調査し、業務プロセスの進捗段階を判定する第２の
   ステップと、 業務プロセスの進捗段階および回付対象のデータ項目並
   びに回付宛先の関係を定義した回付先定義テーブルによ
   り、前記第２のステップで判定した進捗段階において回
   付すべきデータ項目および回付宛先を判定し、そのデー
   タ項目のデータを前記データベースから引出し、判定結
   果の回付宛先の業務処理部門のデータ入出力装置に対し
   て転送する第３のステップとを備えることを特徴とする
   業務プロセスにおけるデータ回付方法。
2. 【請求項２】 前記進捗段階定義テーブルは、各業務処
   理部門に共通の定義と各業務処理部門に固有の定義を備
   えていることを特徴とする請求項１記載の業務プロセス
   におけるデータ回付方法。
3. 【請求項３】 前記回付先定義テーブルは、各業務処理
   部門に共通の定義と各業務処理部門に固有の定義を備え
   ていることを特徴とする請求項１記載の業務プロセスに
   おけるデータ回付方法。
4. 【請求項４】 各データ項目の入力状況および前記パラ
   メータを含む判定条件と業務処理の進捗段階との関係を
   定義する進捗段階定義マトリクスをデータ入出力装置の
   画面に表示し、この進捗段階定義マトリクスに進捗段階
   定義項目および判定条件を入力することにより、前記進
   捗段階定義テーブルを作成することを特徴とする請求項
   １または２記載の業務プロセスにおけるデータ回付方
   法。
5. 【請求項５】 業務プロセスの進捗段階および回付対象
   のデータ項目並びに回付宛先の関係を定義する回付先定
   義マトリクスをデータ入出力装置の画面に表示し、この
   回付先定義マトリクスに進捗段階定義項目および回付対
   象のデータ項目並びに回付宛先の関係を入力することに
   より、前記回付先定義テーブルを作成することを特徴と
   する請求項１または３記載の業務プロセスにおけるデー
   タ回付方法。