JP2003196441A - 業務処理管理システム及びその方法、サーバ装置並びにプログラム - Google Patents

Abstract

(57)【要約】 【課題】 業務プロセスの変更に対して機敏に変更可能
な業務処理管理システムを提供する。 【解決手段】 業務プロセス定義部５は、業務プロセス
を構成する一連の作業工程間の情報の流れを定義する。
共有データベース４は、業務プロセスを構成する一連の
作業工程間で受け渡される情報を記憶する。情報には、
自情報を一意に識別するための自キーと、一連の作業工
程の情報の流れにおける自情報の直前の情報を識別する
ための親キーと、関連する他の業務プロセスの情報の自
キーの値を持つ用途キーとが付加されており、一連の作
業工程間の情報の流れの順および関連する他の業務プロ
セスに関連付けされている。サーバ１は、クライアント
端末３から共有データベース４に対する仕事に必要な情
報の登録が要求されると、業務プロセス定義部５に定義
された業務プロセスを構成する一連の作業工程間の情報
の流れ通りの順序で情報が入力されるように制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は生産管理や販売・物
流などにかかる業務処理をコンピュータによって管理す
る技術に関し、特に業務担当者間で受け渡される情報及
び情報の流れをコンピュータによって管理するシステム
及びその方法に関する。

【０００２】

【従来の技術】一般に企業等における業務プロセスは、
複数の作業工程の一連の流れで構成され、仕事に必要な
情報が作業工程間で適宜伝達されることにより業務が遂
行される。このような仕事に必要な情報の伝達をコンピ
ュータによって管理する場合、業務プロセスを構成する
複数の作業工程間の情報の流れを如何にして管理する
か、或る作業工程から次の作業工程へ受け渡される仕事
に関する情報を如何にして管理するか、関連する仕事ど
うしを如何に関連付けるかが重要である。

【０００３】複数の作業工程間における情報の伝達をコ
ンピュータによって管理する技術の一例が特開平１０−
２１４１１３号公報（以下、文献１と称す）に示されて
いる。この文献１に記載された従来技術では、業務プロ
セスを構成する複数の作業工程のシーケンスを、各作業
工程に１対１に対応付けたレコードを工程順に並べた状
態遷移ルールによって定義し、更に各レコードにおいて
当該作業工程でデータ入力を完了すべきデータ項目を定
義する。また、業務プロセスを構成する作業工程に関連
する全てのデータ項目の内容を掲示板データベースのテ
ーブルに集約し、関連する全ての担当者がこのデータベ
ースを掲示板の形式で共有することにより、作業工程間
で授受されるデータを管理する。掲示板データベース
は、少なくとも１組の掲示板データを保持する。１組の
掲示板データは業務処理システム上で処理される個々の
一連の業務に対応して形成される。掲示板データベース
はまた、現在作業中の状態にある作業工程も管理する。
コンピュータは、掲示板データベース及び状態遷移ルー
ルを参照して、原則として現在作業中の工程に関するデ
ータのみを受け付けることで、作業工程間の情報の流れ
が事前に定義された順序通りになるように制御する。

【０００４】

【発明が解決しようとする課題】近年、激変する事業環
境の影響を受け、頻繁に実施されるＢＰＲ（Business P
rocess Reengineering；ビジネスプロセスリエンジニア
リング）や、生産の現場で日々行われる「カイゼン」と
呼ばれる小集団活動による業務プロセスの変化に合わせ
て、業務処理管理システムを機敏に変更させる必要性が
強く望まれている。特に、ハイテク企業の生産システム
においては、商品のライフサイクルの短命化とあわせ、
日々が業務プロセスの変化の連続であり、今後、この傾
向は一層強まる状況にあるため、業務処理管理システム
の対応の遅れは、プロセス改善の足かせとなる。しかる
に文献１に記載の従来技術では、業務プロセスの変更に
機敏に対応することが容易でないという課題がある。

【０００５】それは次の理由による。文献１に記載の従
来技術では、掲示板データベースにおいて関連付けて記
憶することができる情報は、個々の掲示板データを構成
する情報どうし、つまり状態遷移ルールによって定義さ
れた業務プロセスを構成する複数の作業工程のシーケン
スにかかわる一連のデータどうしに限られ、異なる掲示
板データどうし、つまり業務プロセスどうしは関連付け
ることはできない。これは、関連する仕事は１つの掲示
板データに集約し、必要な全ての情報の流れを１つの掲
示板データで管理しなければならないことを意味する。
従って、或る製品Ａを部品ａ１、ａ２から製造する生産
システムを考えた場合、製品Ａに関連する一連の作業工
程および部品ａ１、ａ２に関連する一連の作業工程を全
て含む一連の作業工程を事前に定義し、この一連の作業
工程の情報の流れを１組の掲示板データで管理する必要
がある。このため、製品Ａ、部品ａ１、ａ２の何れかの
一連の作業工程が変更されると、他の部品や製品の作業
工程に影響がなくても、定義した一連の作業工程全体の
再定義が必要になり、その変更に多大な時間と労力が必
要となる。

【０００６】文献１に記載の従来技術が業務プロセスの
変更に機敏に対応することが容易でない別の理由は、文
献１に記載の従来技術は、業務プロセス毎にそれを構成
する全ての作業工程の流れを一連の流れとして状態遷移
ルールによって定義することで作業工程間の情報の流れ
を管理しているため、複数の業務プロセスで共通に使わ
れる作業工程に変更があったとき、変更すべき状態遷移
ルールが多岐にわたり、変更に多大な時間と労力が必要
となるためである。例えば、作業工程ｋ１→作業工程ｋ
２→作業工程ｋ３から構成される一連の作業工程を全て
の業務プロセスが含む場合、従来技術では、各業務プロ
セスの作業工程の流れの定義中に、「作業工程ｋ１→作
業工程ｋ２→作業工程ｋ３」の定義が含まれるため、業
務改善などにより当該一連の作業工程が「作業工程ｋ１
→作業工程ｋ３」に変更されると、全業務プロセスの作
業工程の定義を修正する必要がある。

【０００７】文献１に記載の従来技術が業務プロセスの
変更に機敏に対応することが容易でない更に別の理由
は、一連の業務プロセスに関連する全てのデータ項目の
内容を掲示板データベースのテーブルに格納しているた
め、或る業務プロセスの変更によって既存の掲示板デー
タベースに存在しないデータ項目が必要となった場合、
そのようなデータ項目を必要とする業務プロセスがほん
の一部のプロセスであっても、新たなデータ項目をデー
タベースのテーブルへ追加する必要があり、そのための
大掛かりな作業が必要になるためである。

【０００８】また、文献１に記載の従来技術では、各担
当者から掲示板データベースに入力されたデータの履歴
を記録しており、必要に応じて入力済のデータを参照す
ることで、業務の現在の状況や業務分析等が或る程度は
行えるようになっている。しかし、掲示板データベース
に入力されるデータは、主に仕事の依頼に関するデータ
に限定されており、依頼に対する実績報告が必ずしも記
録されていないために充分な現状把握や業務分析は行え
ないという課題もある。

【０００９】本発明はこのような事情に鑑みて提案され
たものであり、その目的は、業務プロセスの変更に対し
て機敏に変更可能な業務処理管理システム及びその方法
を提供することにある。

【００１０】本発明の別の目的は、業務の現在状況の把
握や業務分析をより詳しく行うことができる業務処理管
理システム及びその方法を提供することにある。

【００１１】

【課題を解決するための手段】本発明の第１の業務処理
管理システムは、業務プロセスを構成する複数の作業工
程間で受け渡される情報及び情報の流れを管理する業務
処理管理システムであって、業務プロセスを構成する一
連の作業工程間の情報の流れを定義した業務プロセス定
義部と、業務プロセスを構成する一連の作業工程間で受
け渡される情報を、当該業務プロセスを構成する一連の
作業工程間の情報の流れの順および関連する他の業務プ
ロセスに関連付けて記憶する共有データベースと、クラ
イアント端末から前記共有データベースに対する仕事に
必要な情報の入出力を制御するサーバであって、前記業
務プロセス定義部に定義された業務プロセスを構成する
一連の作業工程間の情報の流れ通りの順序で情報が入力
されるように制御するサーバとを備えている。ここで、
共有データベースにおいて一連の作業工程間の情報の流
れの順および関連する他の業務プロセスに関連付けて記
憶する構成としては、例えば、共有データベースに記憶
される情報に、自情報を一意に識別するための自キー
と、一連の作業工程の情報の流れにおける自情報の直前
の情報を識別するための親キーと、関連する他の業務プ
ロセスの情報の自キーの値を持つ用途キーとを設ける構
成を採用することができる。

【００１２】本発明の第２の業務処理管理システムは、
第１の業務処理管理システムにおいて、前記業務プロセ
ス定義部は、一連の作業工程からなる単位業務における
情報の流れを定義した業務手順マスタおよび単位業務間
の情報の流れを定義した業務フローマスタを備えてい
る。

【００１３】本発明の第３の業務処理管理システムは、
第１の業務処理管理システムにおいて、前記共有データ
ベースは、作業工程間で受け渡される情報の情報要素の
うち全ての作業工程で共通な共通情報要素を記憶する共
通テーブルと、それ以外の個別情報要素を記憶するプロ
パティテーブルとを有している。

【００１４】本発明の第４の業務処理管理システムは、
第３の業務処理管理システムにおいて、業務プロセスを
構成する複数の作業工程間で受け渡される情報は、仕事
の依頼にかかるデマンド情報とその依頼された仕事に対
する実績報告にかかるサプライ情報とを含み、前記共通
テーブルは、前記デマンド情報を格納するデマンドテー
ブルと前記サプライ情報を格納するサプライテーブルと
で構成されている。

【００１５】本発明の第５の業務処理管理システムは、
第４の業務処理管理システムにおいて、前記デマンドテ
ーブル及び前記サプライテーブルは、前記デマンド情報
及び前記サプライ情報を格納するデータ項目として、少
なくとも、誰が（Ｗｈｏ）に相当する情報要素を格納す
るデータ項目と、誰に（Ｗｈｏｍ）に相当する情報要素
を格納するデータ項目と、何を（Ｗｈａｔ）に相当する
情報要素を格納するデータ項目と、どうする（Ｈｏｗ−
Ｄｏ）に相当する情報要素を格納するデータ項目とを備
えている。

【００１６】本発明の第６の業務処理管理システムは、
第５の業務処理管理システムにおいて、前記デマンドテ
ーブル及び前記サプライテーブルは、前記デマンド情報
及び前記サプライ情報を格納するデータ項目として、更
に、いつ（Ｗｈｅｎ）に相当する情報要素を格納するデ
ータ項目、どこに（Ｗｈｅｒｅ）に相当する情報要素を
格納するデータ項目、いくつ（Ｈｏｗ−Ｍａｎｙ）に相
当する情報要素を格納するデータ項目、いつまでに（Ｈ
ｏｗ−Ｌｏｎｇ）に相当する情報要素を格納するデータ
項目、いくらで（Ｈｏｗ−Ｍｕｃｈ）に相当する情報要
素を格納するデータ項目のうち、少なくとも１つのデー
タ項目を備えている。

【００１７】また、本発明の第１の業務処理管理方法
は、業務プロセスを構成する複数の作業工程間で受け渡
される情報を記憶する共有データベースと、業務プロセ
スを構成する一連の作業工程間の情報の流れを定義する
業務プロセス定義部とに接続されたサーバ、及び、前記
サーバにネットワーク経由で接続されたクライアント端
末から構成され、業務プロセスを構成する複数の作業工
程間で受け渡される情報及び情報の流れを管理する情報
処理システムにおける業務処理管理方法であって、前記
サーバにおいて、クライアント端末から前記共有データ
ベースに対する仕事に必要な情報の登録要求時、前記業
務プロセス定義部に定義された業務プロセスを構成する
一連の作業工程間の情報の流れ通りの順序であるか否か
を検査するステップと、検査がパスしなかった場合に、
前記サーバにおいて、前記クライアント端末からの要求
を拒否するステップと、検査がパスした場合に、前記サ
ーバにおいて、登録要求された情報を一連の作業工程間
の情報の流れの順および関連する他の業務プロセスに関
連付けて前記共有データベースに登録するステップとを
含んでいる。ここで、共有データベースにおいて一連の
作業工程間の情報の流れの順および関連する他の業務プ
ロセスに関連付けて記憶する方法としては、例えば、前
記共有データベースに記憶される情報に、自情報を一意
に識別するための自キーと、一連の作業工程の情報の流
れにおける自情報の直前の情報を識別するための親キー
と、関連する他の業務プロセスの情報の自キーの値を持
つ用途キーとを付加する方法が採用される。

【００１８】本発明の第２の業務処理管理方法は、第１
の業務処理管理方法において、前記業務プロセス定義部
は、一連の作業工程からなる単位業務における情報の流
れを定義した業務手順マスタおよび単位業務間の情報の
流れを定義した業務フローマスタによって、業務プロセ
スを構成する一連の作業工程間の情報の流れを定義する
ようにしている。

【００１９】本発明の第３の業務処理管理方法は、第１
の業務処理管理方法において、前記共有データベース
は、作業工程間で受け渡される情報の情報要素のうち全
ての作業工程で共通な共通情報要素を記憶する共通テー
ブルと、それ以外の個別情報要素を記憶するプロパティ
テーブルとを有している。

【００２０】本発明の第４の業務処理管理方法は、第３
の業務処理管理方法において、業務プロセスを構成する
複数の作業工程間で受け渡される情報は、仕事の依頼に
かかるデマンド情報とその依頼された仕事に対する実績
報告にかかるサプライ情報とを含み、前記共通テーブル
は、前記デマンド情報を格納するデマンドテーブルと、
前記サプライ情報を格納するサプライテーブルとで構成
される。

【００２１】本発明の第５の業務処理管理方法は、第４
の業務処理管理方法において、前記デマンドテーブル及
び前記サプライテーブルは、前記デマンド情報及び前記
サプライ情報を格納するデータ項目として、少なくと
も、誰が（Ｗｈｏ）に相当する情報要素を格納するデー
タ項目と、誰に（Ｗｈｏｍ）に相当する情報要素を格納
するデータ項目と、何を（Ｗｈａｔ）に相当する情報要
素を格納するデータ項目と、どうする（Ｈｏｗ−Ｄｏ）
に相当する情報要素を格納するデータ項目とを備えるよ
うにしている。

【００２２】本発明の第６の業務処理管理方法は、第５
の業務処理管理方法において、前記デマンドテーブル及
び前記サプライテーブルは、前記デマンド情報及び前記
サプライ情報を格納するデータ項目として、更に、いつ
（Ｗｈｅｎ）に相当する情報要素を格納するデータ項
目、どこに（Ｗｈｅｒｅ）に相当する情報要素を格納す
るデータ項目、いくつ（Ｈｏｗ−Ｍａｎｙ）に相当する
情報要素を格納するデータ項目、いつまでに（Ｈｏｗ−
Ｌｏｎｇ）に相当する情報要素を格納するデータ項目、
いくらで（Ｈｏｗ−Ｍｕｃｈ）に相当する情報要素を格
納するデータ項目のうち、少なくとも１つのデータ項目
を備えるようにしている。

【００２３】

【作用】第１の業務処理管理システム及び方法にあって
は、業務プロセスを構成する一連の作業工程間で受け渡
される情報を、当該業務プロセスを構成する一連の作業
工程間の情報の流れの順だけでなく、関連する他の業務
プロセスに関連付けて共有データベースに記憶できるた
め、業務プロセスの単位を細分化し、階層的に管理する
ことができる。たとえば或る製品Ａを部品ａ１、ａ２か
ら製造する生産システムを考えた場合、製品Ａに関連す
る仕事の一連の作業工程、部品ａ１に関連する仕事の一
連の作業工程、部品ａ２に関連する仕事の一連の作業工
程をそれぞれ業務プロセスとして定義すれば、各業務プ
ロセスの一連の作業工程間の情報の流れ順に仕事に必要
な情報を管理しつつ、部品ａ１および部品ａ２にかかる
情報と製品Ａにかかる情報とを関連付け、全体として或
るまとまった業務処理にかかる情報を管理することがで
きる。こうすると、製品Ａ、部品ａ１、ａ２の何れかの
一連の作業工程が変更された場合には、変更された一連
の作業工程を再定義するだけで済み、業務プロセスの変
更に伴う定義情報の変更箇所を局所化でき、迅速な対応
が可能となる。また、関連付けを用途キーによって行う
ため、製品Ａの情報に部品ａ１、ａ２の情報のコピーを
付随させ、逆に部品ａ１、ａ２の情報に製品Ａの情報の
コピーを付随させる場合のような重複した情報の記憶が
不要となる。

【００２４】第２の業務処理管理システム及び方法にあ
っては、業務プロセスを構成する一連の作業工程間の情
報の流れを、一連の作業工程からなる単位業務における
情報の流れを定義した業務手順マスタと、単位業務間の
情報の流れを定義した業務フローマスタとによって定義
するため、単位業務内における情報の流れの変更は業務
手順マスタの定義を変更することで対処でき、単位業務
間の情報の流れの変更は業務フローマスタの定義を変更
することで対処できる。従って、業務プロセスの変更に
伴う定義情報の変更箇所をより局所化でき、迅速な対応
が可能となる。

【００２５】例えば、作業工程ｐ１→作業工程ｋ１→作
業工程ｋ２→作業工程ｋ３→作業工程ｐ２からなる業務
プロセスＰ、作業工程ｑ１→作業工程ｋ１→作業工程ｋ
２→作業工程ｋ３→作業工程ｑ２からなる業務プロセス
Ｑがあるとき、「作業工程ｐ１→作業工程ｐ２」、「作
業工程ｑ１→作業工程ｑ２」、「作業工程ｋ１→作業工
程ｋ２→作業工程ｋ３」をそれぞれ１つの業務単位Ｘ、
Ｙ、Ｚとして、各業務単位における情報の流れを業務手
順マスタに定義する。また、業務単位Ｘと業務単位Ｚと
の情報の流れ「作業工程ｐ１→作業工程ｋ１、作業工程
ｋ３→作業工程ｐ２」、業務単位Ｙと業務単位Ｚとの情
報の流れ「作業工程ｑ１→作業工程ｋ１、作業工程ｋ３
→作業工程ｑ２」を業務フローマスタに定義する。こう
すると、業務改善などにより業務単位Ｚの作業工程が
「作業工程ｋ１→作業工程ｋ３」に変更されても、業務
単位Ｚの業務手順定義だけを変更するだけで対処でき
る。また、業務プロセスＰ、Ｑにおいて作業工程ｐ２、
ｑ２に続いて別の作業工程を行うように業務プロセスが
変更された場合、別の作業工程を例えば「作業工程ｒ１
→作業工程ｒ２」とすると、これを１つの業務単位Ｗと
して業務手順マスタに定義し、業務単位Ｐと業務単位Ｗ
との情報の流れ「作業工程ｐ２→作業工程ｒ１」、業務
単位Ｑと業務単位Ｗとの情報の流れ「作業工程ｑ２→作
業工程ｒ１」を業務手順に定義することで、新規な作業
工程の追加にも容易に対処することができる。更に、業
務プロセスＰ、Ｑの何れか一方または双方で業務単位Ｚ
を必要としなくなった場合、業務フローマスタから業務
単位Ｘ、Ｙと業務単位Ｚとの情報の流れの定義を削除す
ることで容易に対処することができる。

【００２６】第３の業務処理管理システム及び方法にあ
っては、共有データベースが、作業工程間で受け渡され
るデータの情報要素のうち全ての作業工程で共通な共通
情報要素を記憶する共通テーブルと、それ以外の個別情
報要素を記憶するプロパティテーブルとを有しているた
め、共通情報要素以外の個別情報要素が新たに発生した
場合、プロパティテーブルを追加するだけで対処可能と
なり、本体部分である共通テーブルに新規なデータ項目
を追加するような大掛かりな作業が不要となる。

【００２７】第４の業務処理管理システム及び方法にあ
っては、業務プロセスを構成する複数の作業工程間で受
け渡される情報が、仕事の依頼にかかるデマンド情報と
その依頼された仕事に対する実績報告にかかるサプライ
情報とを含み、デマンド情報はデマンドテーブルを通じ
て受け渡され、サプライ情報はサプライテーブルを通じ
て受け渡される。このように、仕事の依頼に関するデー
タ（デマンド情報）のみならず、その仕事の実績報告
（サプライ情報）をも保存して管理することで、現状把
握や業務分析がより詳細に行える。

【００２８】第５の業務処理管理システム及び方法にあ
っては、前記デマンドテーブル及び前記サプライテーブ
ルのデータ項目が、誰が（Ｗｈｏ）に相当する情報要素
を格納するデータ項目、誰に（Ｗｈｏｍ）に相当する情
報要素を格納するデータ項目、何を（Ｗｈａｔ）に相当
する情報要素を格納するデータ項目、どうする（Ｈｏｗ
−Ｄｏ）に相当する情報要素を格納するデータ項目とし
て汎用的なデータ項目とされ、また第６の業務処理管理
システムにあっても、いつ（Ｗｈｅｎ）に相当する情報
要素を格納するデータ項目、どこに（Ｗｈｅｒｅ）に相
当する情報要素を格納するデータ項目、いくつ（Ｈｏｗ
−Ｍａｎｙ）に相当する情報要素を格納するデータ項
目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相当する情報要
素を格納するデータ項目、いくらで（Ｈｏｗ−Ｍｕｃ
ｈ）に相当する情報要素を格納するデータ項目として汎
用的なデータ項目とされているため、事前に想定した特
定の業務用だけでなく、任意の業務に汎用的に使用する
ことが可能となる。

【００２９】

【発明の実施の形態】次に本発明の実施の形態の例につ
いて図面を参照して詳細に説明する。

【００３０】図１は本発明の一実施の形態にかかる業務
処理管理システムの構成図である。この例の業務処理管
理システムは、サーバ１と、このサーバ１にネットワー
ク２を通じて接続された複数のクライアント端末３とを
含んで構成され、サーバ１には、共有データベース４及
び業務プロセス定義部５が接続され、各クライアント端
末３には表示装置６及び入力装置７が接続されている。
また、サーバ１は、ファイル管理部１１、処理部１２及
び通信制御部１３を備え、各クライアント端末３は、通
信制御部３１及びユーザ入出力部３２を備えている。

【００３１】業務プロセス定義部５は、業務プロセスを
構成する一連の作業工程間で受け渡される情報の種類の
定義及びその情報の流れを定義する記憶装置であり、デ
マンドサプライマスタ５１、業務手順マスタ５２及び業
務フローマスタ５３を有する。本実施の形態では、業務
プロセスを構成する複数の作業工程間で受け渡される情
報には、仕事の依頼にかかるデマンド情報とその依頼さ
れた仕事に対する実績報告にかかるサプライ情報との２
通りがあり、デマンド情報及びサプライ情報にはそれぞ
れ複数の種類がある。デマンド情報の種類をデマンド
種、サプライ情報の種類をサプライ種と呼ぶ。同じ種類
のデマンド情報とサプライ情報とはペアになる。デマン
ドサプライマスタ５１は、業務プロセスで必要な全ての
デマンド情報及びサプライ情報の種類（デマンド種、サ
プライ種）を定義するマスタファイルである。このデマ
ンドサプライマスタ５１に定義されない種類のデマンド
情報及びサプライ情報の登録はサーバ１によって拒否さ
れる。

【００３２】業務手順マスタ５２及び業務フローマスタ
５３は、業務プロセスを構成する一連の作業工程間で受
け渡される情報の流れを定義するマスタファイルであ
る。このうち、業務手順マスタ５２は、一連の作業工程
からなる単位業務における情報の流れを定義し、業務フ
ローマスタ５３は、単位業務間の情報の流れを定義す
る。単位業務は、１つの業務部門内における一連の作業
工程に限定されず、複数の業務部門にまたがる一連の作
業工程とすることができる。

【００３３】共有データベース４は、作業工程間で受け
渡されるデータを記憶するデータベースである。或る業
務を行う担当者がクライアント端末３からサーバ１を通
じて業務上のデータを共有データベース４に登録し、別
の業務を行う担当者がクライアント端末３からサーバ１
を通じて共有データベース４に登録されたデータを参照
することで、作業工程間でのデータの受け渡しが行われ
る。本実施の形態では、共有データベース４は、作業工
程間で受け渡されるデータの情報要素のうち、全ての作
業工程で共通な共通情報要素を記憶する共通テーブル４
１と、それ以外の個別情報要素を記憶する１以上のプロ
パティテーブル４２とを有している。また、共通テーブ
ル４１はデマンドテーブル４３及びサプライテーブル４
４に分けられている。デマンドテーブル４３には、デマ
ンド情報を構成する情報要素のうちの共通情報要素が格
納され、サプライテーブル４４には、サプライ情報を構
成する情報要素のうちの共通情報要素が格納される。

【００３４】デマンドテーブル４３及びサプライテーブ
ル４４は、データ項目として、少なくとも、誰が（Ｗｈ
ｏ）に相当する情報要素を格納するデータ項目と、誰に
（Ｗｈｏｍ）に相当する情報要素を格納するデータ項目
と、何を（Ｗｈａｔ）に相当する情報要素を格納するデ
ータ項目と、どうする（Ｈｏｗ−Ｄｏ）に相当する情報
要素を格納するデータ項目とを備える。これは、一般に
仕事を依頼する場合、最低限、誰が、誰に、何を、どう
するの４要素を伝達すれば良く、依頼された仕事の実績
を報告するには、誰が、誰に、何を、どうしたの４要素
を伝達すれば良いことに基づく。但し、依頼や報告をよ
り詳細に行うために、デマンドテーブル４３及びサプラ
イテーブル４４は、更に、いつ（Ｗｈｅｎ）に相当する
情報要素を格納するデータ項目、どこに（Ｗｈｅｒｅ）
に相当する情報要素を格納するデータ項目、いくつ（Ｈ
ｏｗ−Ｍａｎｙ）に相当する情報要素を格納するデータ
項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相当する情報
要素を格納するデータ項目、いくらで（Ｈｏｗ−Ｍｕｃ
ｈ）に相当する情報要素を格納するデータ項目のうち、
少なくとも１つのデータ項目を備えるようにしても良
い。また、デマンドテーブル４３とサプライテーブル４
４とが同じデータ項目を持っていても良いし、異なるデ
ータ項目を持っていても良い。

【００３５】また、デマンドテーブル４３及びサプライ
テーブル４４は、格納するデマンド情報及びサプライ情
報を一連の作業工程間の情報の流れの順に関連付けて記
憶するためのキーの項目を有している。このためのキー
には、自データを一意に識別する自キーと、一連の作業
工程の情報の流れにおける自データの直前のデータを識
別するための親キーとの２種類がある。或るデータに付
された自キーと同じ内容の親キーを持つデータを探索す
ることで、一連の作業工程の情報の流れ方向にデマンド
情報、サプライ情報を辿ることができ、反対に、或るデ
ータに付された親キーと同じ内容の自キーを持つデータ
を探索することで、一連の作業工程の情報の流れと逆方
向にデマンド情報、サプライ情報を辿ることができる。
また、プロパティテーブル４２に格納される個別情報要
素は、その個別情報要素がどのデマンド情報、サプライ
情報の属性（プロパティ）であるか、つまり、どの共通
情報要素と関連しているかを示すキーの項目を有してい
る。キーの値としては、関連する共通情報要素に付加さ
れた自キーの値が使われる。

【００３６】また、デマンドテーブル４３は、更に、或
る業務プロセスにかかるデマンド情報を他の業務プロセ
スに関連付けるための用途キーを有している。用途キー
には、関連する他の業務プロセスのデマンド情報に設定
された自キーの値が設定される。或る業務プロセスＰの
デマンド情報に付された自キーと同じ内容の用途キーを
持つデマンド情報を探索することで、業務プロセスＰの
下位階層の業務プロセスＱを知ることができ、反対に、
業務プロセスＱのデマンド情報に付された用途キーと同
じ内容の自キーを持つデマンド情報を探索することで、
業務プロセスＱの上位階層の業務プロセスＰを知ること
ができる。

【００３７】以上の共有データベース４及び業務プロセ
ス定義部５は、サーバ１に接続される記憶装置上に格納
される。これらの共有データベース４や各マスタへのア
クセスの管理は、サーバ１のファイル管理部１１によっ
て行われる。なお、共有データベース４及び業務プロセ
ス定義部５並びにファイル管理部１１をネットワークを
介してサーバ１に接続される別のサーバによって実現し
ても良い。

【００３８】クライアント端末３の表示装置６は、共有
データベース４に入力すべきデータや共有データベース
４から出力したデータ等を表示するＣＲＴディスプレ
イ、ＬＣＤ等で構成される。入力装置７は、作業工程間
で受け渡すべきデータや各種のコマンド等を入力する装
置であり、キーボードやマウス等で構成される。ユーザ
入出力部３２は、グラフィカルユーザインタフェースを
実現する処理部であり、共有データベース４から入力し
たデータを予め画面設計された表示画面の様式に合わせ
て表示し、また表示画面上で作成されたデータを共有デ
ータベース４の格納形式に合わせてサーバ１へ送信す
る。通信制御部３１は、ネットワーク２を介してサーバ
１との間で行われるデータ等の送受信を制御する。

【００３９】サーバ１の処理部１２は、クライアント端
末３からの要求に従って共有データベース４に対するデ
ータの入出力を制御する制御部である。出力に際して
は、クライアント端末３から要求されたデータを共有デ
ータベース４から取り出し、ネットワーク２経由で要求
元のクライアント端末３へ送信する。入力に際しては、
クライアント端末３から要求されたデータをネットワー
ク２経由で受信し、共有データベース４に登録する。こ
の際、業務プロセス定義部５に定義された業務プロセス
を構成する一連の作業工程間の情報の流れ通りの順序で
データが入力されるように制御することで、作業工程間
のデータの受け渡しが、事前に定義された順番通りに行
われることを保証する。また、クライアント端末３から
入力を要求されたデータの情報要素のうち共通情報要素
は共通テーブル４１に登録する。共通テーブル４１はデ
マンドテーブル４３とサプライテーブル４４とに分かれ
ているため、デマンド作業工程から出された共通情報要
素はデマンドテーブル４３に、サプライ作業工程から出
された共通情報要素はサプライテーブル４４に、それぞ
れ登録される。クライアント端末３から入力を要求され
たデータの情報要素のうち個別情報要素は、該当するプ
ロパティテーブル４２に登録する。サーバ１の通信制御
部１３は、ネットワーク２を介してクライアント端末３
との間に行われるデータ等の送受信を制御する。

【００４０】サーバ１及びクライアント端末３は、パー
ソナルコンピュータ、ワークステーション等の情報処理
装置によって構成される。サーバ１上のファイル管理部
１１、処理部１２及び通信制御部１３、クライアント端
末３上の通信制御部３１及びユーザ入出力部３２は、サ
ーバ１及びクライアント端末３を構成する情報処理装置
のハードウェアによって、またその記憶装置に格納され
るプログラムを実行することによって実現される。

【００４１】図２は本実施の形態にかかる業務処理管理
システムのより詳しい説明を行うために便宜上想定した
業務プロセスのモデルを示す。Ａ、Ｂ、Ｃ、Ｄ、Ｅの５
つの作業工程があり、これら複数の作業工程間でＤ１〜
Ｄ３、Ｓ１〜Ｓ３のデータが受け渡される。このうち、
Ｄ１〜Ｄ３はそれぞれ異なる種類のデマンド情報を示
し、Ｓ１〜Ｓ３はそれぞれ異なる種類のサプライ情報を
示す。また、Ｄ１とＳ１、Ｄ２とＳ２、Ｄ３とＳ３はそ
れぞれペアとなるデマンド情報及びサプライ情報であ
る。業務プロセスとしては、作業工程Ａから始まる業務
プロセスＰと、作業工程Ｂから始まる業務プロセスＱと
が存在し、双方の業務プロセスＰ、Ｑは同じ作業工程
Ｃ、Ｄ、Ｅを含んでいる。業務プロセスＰでは、作業工
程Ａ→作業工程Ｃ→作業工程Ｄ→作業工程Ｃ→作業工程
Ｅ→作業工程Ｃ→作業工程Ａの順で業務が行われ、業務
プロセスＱでは、作業工程Ｂ→作業工程Ｃ→作業工程Ｄ
→作業工程Ｃ→作業工程Ｅ→作業工程Ｃ→作業工程Ｂの
順で業務が行われる。一連の作業工程中に同じ作業工程
が現れているが、これは１つの作業工程が幾つかの作業
工程に分かれていることを想定している。また、一連の
作業工程からなる単位業務として、図２に示す単位業務
Ｘ、Ｙ、Ｚを想定する。さらに、業務プロセスＰは業務
プロセスＱの上位階層のプロセスとする。上位階層のプ
ロセスとは、自プロセスの業務を遂行するに際して下位
階層のプロセスの業務を必要とするプロセスを意味す
る。例えば、部品ａ１で作られる製品Ａがあるとき、製
品Ａにかかる業務プロセスは部品ａ１にかかる業務プロ
セスの上位階層のプロセスであり、部品ａ１にかかる業
務プロセスは製品Ａにかかる業務プロセスの下位階層の
プロセスである。

【００４２】図３はデマンドサプライマスタ５１の論理
的な構成例を示す。図３に示すように、デマンドサプラ
イマスタ５１には、デマンド種５１−１とサプライ種５
１−２とがペアで定義される。図２のモデルの場合、Ｄ
１とＳ１、Ｄ２とＳ２、Ｄ３とＳ３がそれぞれのレコー
ドＲ１１〜Ｒ１３に登録される。

【００４３】図４は業務手順マスタ５２の論理的な構成
例を示す。図４に示すように、業務手順マスタ５２に
は、各単位業務における作業工程間で受け渡す個々のデ
マンド情報及びサプライ情報毎に、そのデマンド／サプ
ライ種５２−３と、手順区分５２−１、親デマンド／サ
プライ種５２−２、順序５２−４、種別５２−５とがそ
れぞれのレコードＲ２１〜Ｒ２８に定義される。手順区
分５２−１は単位業務を一意に識別する識別子であり、
親デマンド／サプライ種５２−２は当該単位業務内にお
ける当該デマンド／サプライ種５２−３の直前に受け渡
されるデマンド／サプライ種を示し、順序５２−４は当
該単位業務内における当該デマンド／サプライ種の順番
を示し、種別５２−５は当該デマンド／サプライ種がデ
マンド種か、サプライ種かの種別を示す。図２のモデル
の場合、単位業務Ｘ及び単位業務Ｙにはデマンド種Ｄ
１、サプライ種Ｓ１の２つがあり、単位業務Ｚにはデマ
ンド種Ｄ２、Ｄ３、サプライ種Ｓ２、Ｓ３の４つがある
ため、それらについて図４に示されるように定義されて
いる。

【００４４】例えばレコードＲ２２は、単位業務Ｘにお
いて、サプライ種Ｓ１は、デマンド種Ｄ１の次に引き渡
される情報であり、その順番は２番目であることを示
す。また、業務単位Ｘ及び業務単位Ｙのデマンド種Ｄ１
について親デマンド／サプライ種５２−２に「−」が設
定されているのは、このデマンド種Ｄ１は最初に受け渡
されるデマンド種であることを示す。なお、図４に示す
ように、単位業務Ｘ、Ｙ、Ｚにおける情報の流れ順に定
義レコードＲ２１〜Ｒ２８を並べる場合、各単位業務に
おける情報の流れはレコードの順序で一意に決定される
ので、順序５２−４を省略することもできる。また、種
別５２−５を設けているが、デマンド／サプライ種５２
−３に設定されるデマンド種及びサプライ種のコード自
体でデマンド種か、サプライ種かを判別できる場合には
省略しても良い。

【００４５】図５は業務フローマスタ５３の構成例を示
す。図５に示すように、業務フローマスタ５３には、単
位業務間をまたがる情報の流れ毎に、飛び戻り区分５３
−１、親手順区分５３−２、親デマンド／サプライ種５
３−３、手順区分５３−４、デマンド／サプライ種５３
−５がレコードＲ３１〜Ｒ３４によって定義される。飛
び戻り区分５３−１には、或る単位業務から別の単位業
務へ飛ぶ流れにはその旨を示すコード「Ｇ」が設定さ
れ、飛んだ先の単位業務から元の単位業務へ戻る流れに
はその旨を示すコード「Ｒ」が設定される。親手順区分
５３−２及び親デマンド／サプライ種５３−３には、情
報の流れの上流側の単位業務及びデマンド／サプライ種
が設定され、手順区分５３−４及びデマンド／サプライ
種５３−５には、情報の流れの下流側の単位業務及びデ
マンド／サプライ種が設定される。例えば、レコードＲ
３１は、単位業務Ｘのデマンド種Ｄ１の次は単位業務Ｚ
のデマンド種Ｄ２に情報の流れが飛ぶことを示し、レコ
ードＲ３２は、単位業務Ｚのサプライ種Ｓ３の次は単位
業務Ｘのサプライ種Ｓ１に情報の流れが戻ることを示
す。

【００４６】単位業務間の情報の流れを定義した業務フ
ローマスタ５３は、単位業務における情報の流れを定義
した業務手順マスタ５２より優先される。例えば、図４
のレコードＲ２２は、単位業務Ｘにおけるサプライ種Ｓ
１は、単位業務Ｘにおけるデマンド種Ｄ１を親デマンド
種としているが、図５のレコードＲ３１は、単位業務Ｚ
のデマンド種Ｄ１から単位業務Ｚのデマンド種Ｄ２に情
報の流れが飛ぶことを定義してあるため、情報の流れ
は、単位業務Ｘのデマンド種Ｄ１→単位業務Ｚのデマン
ド種Ｄ２となる。結局、図４の業務手順マスタ５２及び
図５の業務フローマスタ５３によって、以下のような２
つの情報の流れが定義されていることになる。（ｐ）業
務単位Ｘのデマンド種Ｄ１→業務単位Ｚのデマンド種Ｄ
２→業務単位Ｚのサプライ種Ｓ２→業務単位Ｚのデマン
ド種Ｄ３→業務単位Ｚのサプライ種Ｓ３→業務単位Ｘの
サプライ種Ｓ１（ｑ）業務単位Ｙのデマンド種Ｄ１→業
務単位Ｚのデマンド種Ｄ２→業務単位Ｚのサプライ種Ｓ
２→業務単位Ｚのデマンド種Ｄ３→業務単位Ｚのサプラ
イ種Ｓ３→業務単位Ｙのサプライ種Ｓ１

【００４７】図６はデマンドテーブル４３及びサプライ
テーブル４４のデータ項目の一例を示す。デマンドテー
ブル４３は、図６（ａ）に示すように、仕事の要求元を
示すデータ項目４３−１、仕事の要求先を示すデータ項
目４３−２、要求日時を示すデータ項目４３−３、要求
場所を示すデータ項目４３−４、要求する仕事の対象物
を示すデータ項目４３−５、対象物の数を示すデータ項
目４３−６、仕事の期限を示すデータ項目４３−７、価
格を示すデータ項目４３−８、要求する仕事の種類をデ
マンド種と手順区分で示すデータ項目４３−９、自キー
４３−Ａ、親キー４３−Ｂ及び用途キー４３−Ｃを有す
る。データ項目４３−１〜４３−９は、デマンド情報を
構成する情報要素のうち共通情報要素を格納するデータ
項目である。自キー４３−Ａは当該デマンド情報を一意
に識別するためのキーを格納する項目である。自キー４
３−Ａは、デマンド情報を登録する業務担当者が設定す
る手動設定部分キーと、サーバ１側で設定される自動設
定部分キーとから構成される。手動設定部分キーは、デ
ータ項目４３−１〜４３−９と物理的に独立に備える以
外に、データ項目４３−１〜４３−９の一部を手動設定
部分キーとして兼用しても良い。親キー４３−Ｂは一連
の作業工程の情報の流れにおける当該デマンド情報の直
前の情報（デマンド情報またはサプライ情報）に付され
た自キーを格納する項目である。用途キー４３−Ｃは当
該デマンド情報が属する業務プロセスの上位階層の業務
プロセスにおけるデマンド情報に付与された自キーを格
納する項目である。

【００４８】また、サプライテーブル４４は、図６
（ｂ）に示すように、実績の報告元を示すデータ項目４
４−１、実績の報告先を示すデータ項目４４−２、報告
日時を示すデータ項目４４−３、報告場所を示すデータ
項目４４−４、報告する対象物を示すデータ項目４４−
５、対象物の数を示すデータ項目４４−６、計上日を示
すデータ項目４４−７、価格を示すデータ項目４４−
８、報告する実績の種類をサプライ種と手順区分で示す
データ項目４４−９、自キー４４−Ａ及び親キー４４−
Ｂを、各データ項目として有する。データ項目４４−１
〜４４−９は、サプライ情報を構成する情報要素のうち
共通情報要素を格納するデータ項目である。自キー４４
−Ａは当該サプライ情報を一意に識別するためのキーを
格納する項目である。自キー４４−Ａは、サプライ情報
を登録する業務担当者が設定する手動設定部分キーと、
サーバ１側で設定される自動設定部分キーとから構成さ
れる。手動設定部分キーは、データ項目４４−１〜４４
−９と物理的に独立に備える以外に、データ項目４４−
１〜４４−９の一部を手動設定部分キーとして兼用して
も良い。親キー４４−Ｂは一連の作業工程の情報の流れ
における当該サプライ情報の直前の情報（デマンド情報
またはサプライ情報）に付された自キーを格納する項目
である。

【００４９】図７はプロパティテーブル４２の論理的な
構成例を示す。図７に示すようにプロパティテーブル４
２は、キー情報の項目４２−１とプロパティの項目４２
−２を有する。プロパティの項目４２−２には、デマン
ド情報またはサプライ情報の個別情報要素が格納され
る。キー情報の項目４２−１には、その個別情報要素が
どのデマンド情報、サプライ情報に属するかを示す自キ
ーが格納される。自キーは、図６に示した自キー４３−
Ａ、４４−Ａに相当する。

【００５０】図８はデマンド情報及びサプライ情報を共
有データベース４へ登録する際の処理例を示し、図８
（ａ）はクライアント端末３側の処理を、図８（ｂ）は
サーバ１側の処理をそれぞれ示す。

【００５１】クライアント端末３の業務担当者は、デマ
ンド情報を共有データベース４へ登録する際、共通情報
要素だけのデマンド情報で済む場合には、図６（ａ）に
示したデータ項目４３−１〜４３−Ｃに対応するデータ
項目に必要な値を設定した１つの入力用テーブルを作成
し、個別情報要素の登録も行う場合には、個別情報要素
の種別に応じた入力用テーブルも併せて作成する（ステ
ップＳ３０１）。これらの入力用テーブルの作成は、ユ
ーザ入出力部３２によって表示装置６の画面に表示され
るデマンド入力画面に対し、入力装置７からデータを入
力していくことで行われる。その際、親キー４３−Ｂや
用途キー４３−Ｃの内容は、後述するように共有データ
ベース４の内容を参照することで知ることができる。サ
プライ情報を共有データベース４へ登録する際も同様
に、共通情報要素だけのサプライ情報で済む場合には、
図６（ｂ）に示したデータ項目４４−１〜４４−Ｂに対
応するデータ項目に必要な値を設定した１つの入力用テ
ーブルを作成し、個別情報要素の登録も行う場合には、
個別情報要素の種別に応じた入力用テーブルも併せて作
成する（ステップＳ３０１）。このような入力用テーブ
ルの作成も、ユーザ入出力部３２によって表示装置６の
画面に表示されるサプライ入力画面に対し、入力装置７
からデータを入力していくことで可能である。

【００５２】次にクライアント端末３は、ネットワーク
２を通じてサーバ１に接続し、デマンド登録時はデマン
ド登録要求と作成した入力用テーブルとをサーバ１に送
信し、サプライ登録時にはサプライ登録要求と作成した
入力用テーブルとをサーバ１に送信する（ステップＳ３
０２）。この入力用テーブルのクライアント端末３から
サーバ１への送信は、クライアント端末３から自発的に
行っても良いし、デマンド登録要求、サプライ登録要求
を受けたサーバ１がクライアント端末３から入力用テー
ブルをネットワーク２経由で取り出すことで実現しても
良い。その後、クライアント端末３はサーバ１からの応
答を待ち、ネットワーク２経由で応答が返されると、そ
れを受信し、応答内容を表示装置６に表示する（ステッ
プＳ３０３）。

【００５３】他方、サーバ１の処理部１２は、クライア
ント端末３からデマンド登録要求またはサプライ登録要
求および入力用テーブルを受信すると（ステップＳ１０
１）、業務プロセス定義部５に定義された一連の作業工
程間の情報の流れ通りの順序でデマンド情報またはサプ
ライ情報の登録が行われているか否かを調べる登録可否
チェックを実施する（ステップＳ１０２）。このチェッ
クの具体的な処理は後述する。登録可能と判断した場合
（ステップＳ１０３でＹＥＳ）、処理部１２は、登録要
求されたデマンド情報またはサプライ情報を共有データ
ベース４へ登録する（ステップＳ１０４）。

【００５４】具体的には、デマンド情報の登録要求の場
合、共通情報要素が設定された入力用テーブルの自キー
４３−Ａ中の自動設定部分キーをサーバ側で採番して自
キー４３−Ａを完成させ、この入力用テーブルの内容を
持つ行をデマンドテーブル４３に追加する。また、個別
情報要素の種別に応じた入力用テーブルが付随している
場合は、その種別に応じたプロパティテーブル４２に当
該入力用テーブルの内容を追加する。このとき、図７に
示したキー情報４２−１に自キー４３−Ａを設定するこ
とにより、個別情報要素を共通情報要素と関連付ける。
サプライ情報の登録要求の場合もほぼ同様であり、共通
情報要素が設定された入力用テーブルの自キー４４−Ａ
中の自動設定部分キーをサーバ側で採番して自キー４４
−Ａを完成させて、入力用テーブルの内容を持つ行をサ
プライテーブル４４に追加し、個別情報要素の種別に応
じた入力用テーブルが付随している場合は、その種別に
応じたプロパティテーブル４２に当該入力用テーブルの
内容を追加する。また、図７に示したキー情報４２−１
に自キー４４−Ａを設定し、個別情報要素を共通情報要
素と関連付ける。

【００５５】サーバ１の処理部１２は、デマンド情報ま
たはサプライ情報の共有データベース４への登録処理を
終えると、その旨を要求元のクライアント端末３へ通知
する（ステップＳ１０５）。他方、登録要求されたデマ
ンド情報またはサプライ情報が、業務プロセス定義部５
に定義された一連の作業工程間の情報の流れ通りの順序
でないため登録不可と判断した場合（ステップＳ１０３
でＮＯ）、サーバ１の処理部１２はエラーメッセージを
要求元のクライアント端末３へ通知する（ステップＳ１
０６）。

【００５６】サーバ１の処理部１２が行う登録可否チェ
ック（Ｓ１０２）の詳細な処理の一例を図９に示す。先
ず処理部１２は、登録要求されたデマンド情報またはサ
プライ情報のデータ項目４３−９または４４−９に設定
されたデマンド種またはサプライ種が、デマンドサプラ
イマスタ５１に定義されているか否かを調べ（ステップ
Ｓ１１１）、定義されていなければ登録不可と判断す
る。同時に、このステップＳ１１１において、登録要求
された情報がデマンド情報であって、用途キー４３−Ｃ
がＮＵＬＬでないとき、その用途キー４３−Ｃに適合す
る自キーを持つ他のデマンド情報が既に登録されている
か否かを調べ、登録されていなければ登録不可と判断す
る。

【００５７】登録要求されたデマンド情報またはサプラ
イ情報のデマンド種またはサプライ種がデマンドサプラ
イマスタ５１に定義されており、且つ、登録要求された
情報がデマンド情報であって、用途キー４３−ＣがＮＵ
ＬＬでないときにその用途キー４３−Ｃに適合する自キ
ーを持つ他のデマンド情報が既に登録されている場合、
データ項目４３−Ｂまたは４４−Ｂに親キーが設定され
ているか否かを調べ（ステップＳ１１２）、親キーの設
定の有無により処理を切りわける。

【００５８】親キーが設定されていない場合、デマンド
情報またはサプライ情報のデータ項目４３−９または４
４−９に設定された手順区分及びデマンド種またはサプ
ライ種が、業務プロセスの最初に受け渡される情報とし
て定義されているか否かを業務手順マスタ５２でチェッ
クする（ステップＳ１１３）。このチェックにパスしな
ければ（ステップＳ１１４でＮＯ）、登録不可と判断す
る。なお、サプライ情報は業務プロセスの最初に受け渡
される情報になり得ないので、親キーの設定がないサプ
ライ情報の登録要求は直ちに登録不可と判断して良い。
ステップＳ１１３のチェックにパスした場合、重複登録
が行われているか否かをチェックし（ステップＳ１１
５）、重複登録の場合には登録不可と判断し、そうでな
い場合には登録可と判断する。ここで、重複登録とは、
デマンド情報またはサプライ情報における自キー４３−
Ａ、４４−Ａ中の手動設定部分キーと同じ手動設定部分
キーを自キーに持つデマンド情報またはサプライ情報
が、デマンドテーブル４３またはサプライテーブル４４
に既に登録されている状態を意味する。

【００５９】他方、親キーが設定されている場合、その
親キーと同じ内容を自キー４３−Ａ、４４−Ａに持つデ
マンド情報またはサプライ情報（親デマンドまたは親サ
プライ）をデマンドテーブル４３またはサプライテーブ
ル４４から探索し（ステップＳ１１６）、そのような親
デマンドまたは親サプライが存在しなければ（ステップ
Ｓ１１７でＮＯ）、登録不可と判断する。親デマンドま
たは親サプライが存在していた場合（ステップＳ１１７
でＹＥＳ）、この存在していた親デマンドまたは親サプ
ライの次に受け渡される情報が今回登録要求されたデマ
ンド情報またはサプライ情報であるか否かを、業務手順
マスタ５２及び業務フローマスタ５３を参照してチェッ
クする（ステップＳ１１８）。このチェックにパスしな
ければ（ステップＳ１１９でＮＯ）、登録不可と判断す
る。チェックにパスした場合（ステップＳ１１９でＹＥ
Ｓ）、ステップＳ１１５に進んで重複登録が行われてい
るか否かをチェックし、重複登録の場合には登録不可と
判断し、そうでない場合には登録可と判断する。

【００６０】図１０に、デマンド情報及びサプライ情報
が一連の作業工程間の情報の流れの順に関連付けて記憶
されている様子を示す。ここでは、７個のデマンド情報
（１）〜（７）と３個のサプライ情報（１）〜（３）が
存在する。このうち、デマンド情報（１）、（２）、
（５）及びサプライ情報（１）〜（３）は、業務プロセ
スＰの或る仕事Ｐ００１に関する一連の情報を示し、デ
マンド情報（３）、（７）は業務プロセスＰの別の仕事
Ｐ００２に関する一連の情報を示し、デマンド情報
（４）、（６）は業務プロセスＰに関連する別の業務プ
ロセスＱの或る仕事Ｑ００１に関する一連の情報を示
す。

【００６１】業務プロセスＰの或る仕事Ｐ００１に関す
る最初の情報であるデマンド情報（１）は、データ項目
４３−９に手順区分Ｘとデマンド種Ｄ１が設定され、自
キー４３−Ａに「Ｐ００１−０１」が設定され、親キー
４３−Ｂおよび用途キー４３−ＣはＮＵＬＬになってい
る。自キー中の「Ｐ００１」は、業務プロセスＰの仕事
Ｐ００１を同じ業務プロセスＰや他の業務プロセスＱの
仕事と区別するために業務担当者が付与した手動設定部
分キーであり、自キー中の「０１」は処理部１２が付与
した自動設定部分キーである。情報の流れの順でデマン
ド情報（１）の次の情報であるデマンド情報（２）は、
データ項目４３−９に手順区分Ｚとデマンド種Ｄ２が設
定され、自キー４３−Ａに「Ｐ００１−０２」が設定さ
れ、親キー４３−Ｂにデマンド情報（１）の自キーの値
「Ｐ００１−０１」が設定され、用途キー４３−ＣはＮ
ＵＬＬである。情報の流れの順でデマンド情報（２）の
次の情報であるサプライ情報（１）は、データ項目４４
−９に手順区分Ｚとサプライ種Ｓ２が設定され、自キー
４４−Ａに「Ｐ００１−０２−１」が設定され、親キー
４４−Ｂにデマンド情報（２）の自キーの値「Ｐ００１
−０２」が設定されている。自キー４４−Ａに設定され
た自キー中の「Ｐ００１−０２」は、当該サプライ情報
がデマンド情報（２）に対するサプライであることを示
すために業務担当者が付与した手動設定部分キーであ
り、自キー中の最後尾の「１」は処理部１２が付与した
自動設定部分キーである。以下同様にして、業務プロセ
スＰの仕事Ｐ００１に関するデマンド情報（５）、サプ
ライ情報（２）、サプライ情報（３）が順次に関係付け
られている。

【００６２】業務プロセスＰの仕事Ｐ００２に関する最
初の情報であるデマンド情報（３）は、データ項目４３
−９に手順区分Ｘとデマンド種Ｄ１が設定され、自キー
４３−Ａに「Ｐ００２−０１」が設定され、親キー４３
−Ｂおよび用途キー４３−ＣはＮＵＬＬになっている。
自キー中の「Ｐ００２」は、業務プロセスＰの仕事Ｐ０
０２を同じ業務プロセスＰや他の業務プロセスＱの仕事
と区別するために業務担当者が付与した手動設定部分キ
ーであり、自キー中の「０１」は処理部１２が付与した
自動設定部分キーである。情報の流れの順でデマンド情
報（３）の次の情報であるデマンド情報（７）は、デー
タ項目４３−９に手順区分Ｚとデマンド種Ｄ２が設定さ
れ、自キー４３−Ａに「Ｐ００２−０２」が設定され、
親キー４３−Ｂにデマンド情報（３）の自キーの値「Ｐ
００２−０１」が設定され、用途キー４３−ＣはＮＵＬ
Ｌである。業務プロセスＰの仕事Ｐ００２に関する情報
は、現時点ではここまでが登録されている。

【００６３】業務プロセスＱの仕事Ｑ００１に関する最
初の情報であるデマンド情報（４）は、データ項目４３
−９に手順区分Ｙとデマンド種Ｄ１が設定され、自キー
４３−Ａに「Ｑ００１−０１」が設定され、親キー４３
−ＢにＮＵＬＬが設定され、用途キー４３−Ｃに業務プ
ロセスＰの仕事Ｐ０００１に関する最初のデマンド情報
（１）の自キー４３−Ａの値が設定されている。自キー
中の「Ｑ００１」は、業務プロセスＱの仕事Ｑ００１を
同じ業務プロセスＱや他の業務プロセスＰの仕事と区別
するために業務担当者が付与した手動設定部分キーであ
り、自キー中の「０１」は処理部１２が付与した自動設
定部分キーである。情報の流れの順でデマンド情報
（４）の次の情報であるデマンド情報（６）は、データ
項目４３−９に手順区分Ｚとデマンド種Ｄ２が設定さ
れ、自キー４３−Ａに「Ｑ００１−０２」が設定され、
親キー４３−Ｂにデマンド情報（４）の自キーの値「Ｑ
００１−０１」が設定され、用途キー４３−Ｃにデマン
ド情報（１）の自キー４３−Ａの値が設定されている。
このように同じ仕事Ｑ００１に関する全てのデマンド情
報の用途キー４３−Ｃの値は同じである。業務プロセス
Ｑの仕事Ｑ００１に関する情報は、更に続くが、図１０
では図示を省略してある。

【００６４】図９に示した登録可否チェック処理では、
デマンド情報またはサプライ情報における自キー４３−
Ａ、４４−Ａ中の手動設定部分キーと同じ手動設定部分
キーを自キーに持つデマンド情報またはサプライ情報
は、重複登録として登録を拒否した。しかし、業務の種
類やデマンド種、サプライ種によっては、或る１つの仕
事を複数に分割して依頼したり、１つの依頼に対して実
績を複数回に分けて報告することが行われている。従っ
て、そのような場合には重複登録を認める必要がある。
この場合、図９のステップＳ１１５は図１１のステップ
Ｓ１１５−１〜Ｓ１１５−３のように変形される。即
ち、今回登録を要求されたデマンド情報またはサプライ
情報における自キー４３−Ａ、４４−Ａ中の手動設定部
分キーと同じ手動設定部分キーを自キーに持つデマンド
情報またはサプライ情報が、デマンドテーブル４３また
はサプライテーブル４４に既に登録されていた場合（ス
テップＳ１１５−１でＹＥＳ）、重複登録制御マスタを
チェックして、今回登録を要求された手順区分及びデマ
ンド種またはサプライ種が重複登録可能として定義され
ているか否かを調べ（ステップＳ１１５−２）、重複登
録可能として定義されている場合に限り（ステップＳ１
１５−３でＹＥＳ）、登録可と判断する。ここで、重複
登録制御マスタは、重複登録を認める手順区分とデマン
ド種またはサプライ種の組を定義したマスタであり、図
１の業務プロセス定義部５に含められる。

【００６５】図１２に、上述のような重複登録を認めた
場合におけるデマンド情報及びサプライ情報の関連付け
の例を示す。デマンド情報（１−１）、（１−２）は、
１つのデマンド情報を２つに分けて登録したもので、デ
マンド情報（１−１）は、データ項目４３−９に手順区
分Ｘとデマンド種Ｄ１が設定され、自キー４３−Ａに
「Ｐ００１−０１」が設定され、親キー４３−Ｂおよび
用途キー４３−ＣはＮＵＬＬになっており、デマンド情
報（１−２）は、データ項目４３−９に手順区分Ｘとデ
マンド種Ｄ１が設定され、自キー４３−Ａに「Ｐ００１
−０２」が設定され、親キー４３−Ｂおよび用途キー４
３−ＣはＮＵＬＬになっている。つまり、自キー４３−
Ａの手動設定部分キーは同じ「Ｐ００１」であり、両者
を区別するために処理部１２がそれぞれ異なる自動設定
部分キー「０１」、「０２」を付与している。デマンド
情報（２−１）は、情報の流れの順でデマンド情報（１
−１）の次の情報になるデマンド情報であり、データ項
目４３−９に手順区分Ｚとデマンド種Ｄ２が設定され、
自キー４３−Ａに「Ｐ００１−０３」が設定され、親キ
ー４３−Ｂにデマンド情報（１−１）の自キーの値「Ｐ
００１−０１」が設定され、用途キー４３−ＣはＮＵＬ
Ｌである。

【００６６】サプライ情報（１−１）、（１−２）は、
デマンド情報（２−１）に対するサプライ情報を２つに
分けて登録したもので、サプライ情報（１−１）は、デ
ータ項目４４−９に手順区分Ｚとサプライ種Ｓ２が設定
され、自キー４４−Ａに「Ｐ００１−０３−１」が設定
され、親キー４４−Ｂにデマンド情報（２−１）の自キ
ーの値「Ｐ００１−０３」が設定されており、サプライ
情報（１−２）は、データ項目４４−９に手順区分Ｚと
サプライ種Ｓ２が設定され、自キー４４−Ａに「Ｐ００
１−０３−２」が設定され、親キー４４−Ｂにデマンド
情報（２−１）の自キーの値「Ｐ００１−０３」が設定
されている。

【００６７】デマンド情報（２−２）は、情報の流れの
順でデマンド情報（１−２）の次の情報になるデマンド
情報であり、データ項目４３−９に手順区分Ｚとデマン
ド種Ｄ２が設定され、自キー４３−Ａに「Ｐ００１−０
４」が設定され、親キー４３−Ｂにデマンド情報（１−
２）の自キーの値「Ｐ００１−０２」が設定され、用途
キー４３−ＣはＮＵＬＬである。

【００６８】デマンド情報（４−１）、（４−２）は、
デマンド情報（１−１）、（１−２）が属する業務プロ
セスの下位階層の業務プロセスのデマンド情報を２つに
分けて登録したもので、デマンド情報（４−１）は、デ
ータ項目４３−９に手順区分Ｙとデマンド種Ｄ１が設定
され、自キー４３−Ａに「Ｑ００１−０１」が設定さ
れ、親キー４３−ＢにＮＵＬＬが設定され、用途キー４
３−Ｃにデマンド情報（１−１）の自キー４３−Ａの値
が設定されている。また、デマンド情報（４−２）は、
データ項目４３−９に手順区分Ｙとデマンド種Ｄ１が設
定され、自キー４３−Ａに「Ｑ００１−０２」が設定さ
れ、親キー４３−ＢはＮＵＬＬであり、用途キー４３−
Ｃにはデマンド情報（１−２）の自キー４３−Ａの値が
設定されている。

【００６９】図１３は共有データベース４に登録された
デマンド情報及びサプライ情報を参照する際の処理例を
示し、図１３（ａ）はクライアント端末３側の処理を、
図１３（ｂ）はサーバ１側の処理をそれぞれ示す。

【００７０】クライアント端末３の業務担当者は、共有
データベース４に登録されたデマンド情報、サプライ情
報を参照する場合、検索キーおよびその他の検索条件を
指定してネットワーク２経由でサーバ１へ参照要求を送
信する（ステップＳ３１１）。検索キーとしては、手順
区分、デマンド種、サプライ種、自キー中の手動設定部
分キー、用途キーの値、個別情報要素の種別、それらの
組み合わせなど、予め検索キーとして定義された任意の
キーを使用することができる。その後、クライアント端
末３はサーバ１からの応答を待ち、サーバ１からネット
ワーク２経由でデマンド情報、サプライ情報が送信され
てくると、それを受信し、表示装置６に表示する（ステ
ップＳ３１２）。

【００７１】他方、サーバ１の処理部１２は、ネットワ
ーク２経由でクライアント端末３から参照要求を受信す
ると（ステップＳ１２１）、指定された検索キーおよび
その他の検索条件で共有データベース４のデマンドテー
ブル４３、サプライテーブル４４、プロパティテーブル
４２を検索し、該当するデマンド情報、サプライ情報を
取り出す（ステップＳ１２２）。そして、取り出したデ
マンド情報、サプライ情報をネットワーク２経由でクラ
イアント端末３へ送信する（ステップＳ１２３）。

【００７２】例えば、図１０に示したようなデマンド情
報およびサプライ情報が登録されている状態で、検索キ
ーとして自キー４３−Ａの手動設定部分キーＰ００１を
指定し、関連するデマンド情報およびサプライ情報の検
索を行った場合、デマンド情報（１）、（２）、サプラ
イ情報（１）、デマンド情報（５）、サプライ情報
（２）、（３）が検索され、クライアント端末３に表示
される。これにより、業務プロセスＰの仕事Ｐ００１の
進捗状況などを把握することができる。

【００７３】また、検索キーとしてＰ００１−０１を指
定して関連下位階層プロセスの検索を行えば、Ｐ００１
−０１を自キー４３−Ａに持つ業務プロセスＰの或る仕
事Ｐ００１にかかるデマンド情報（１）と、Ｐ００１−
０１を用途キー４３−Ｃに持つ業務プロセスＱの仕事Ｑ
００１にかかるデマンド情報（４）、（６）が検索さ
れ、例えば図１４（ａ）に示すようにクライアント端末
３に表示される。これにより、業務プロセスＰの下位階
層の業務プロセスＱの仕事の進捗状況などを把握するこ
とができる。図１０では、仕事Ｐ００１の下位には仕事
Ｑ００１しか存在しなかったが、複数存在する場合に
は、図１４（ｂ）に示すように関連する全ての下位階層
の業務プロセスの仕事にかかるデマンド情報等が検索さ
れて表示される。また、図１０では、仕事Ｑ００１に関
連する下位階層の業務プロセスは存在しなかったが、若
し存在する場合には、図１４（ｃ）に示すように更に下
位の業務プロセスにかかるデマンド情報等が検索されて
表示される。関連する下位階層プロセスの検索とは逆
に、関連する上位階層プロセスの検索も同様に可能であ
る。

【００７４】以上の説明では、用途キー４３−Ｃは、関
連する他の仕事にかかるデマンド情報の自キー４３−Ａ
の値すべてを持つものとした。別の実施の形態として、
用途キー４３−Ｃに、自キー４３−Ａの値のうちの手動
設定部分キーだけを設定するようにしても良い。

【００７５】

【実施例】次に本発明の実施の形態の実施例について図
面を参照して詳細に説明する。本発明は、複数の作業工
程から構成される業務プロセスを遂行する企業等であれ
ば業種や業態にかかわらず広く適用可能である。以下で
は、一例として生産システムに本発明を適用した実施例
を説明する。

【００７６】先ず、図１５及び図１６にそれぞれ異なる
生産システムの例を示す。図１５の生産システムは、計
画部門を中心としたプッシュ型の生産方式である。顧客
（事業部）６１０から受注を受けた計画部門６２０が、
部品構成（ＢＭ）展開を行い、部材手配や生産指示を、
資材部門６４０や製造検査部門６３０に対して実施す
る。図１５において、白抜き矢印はデマンド情報、ハッ
チングを施した矢印はサプライ情報を表しており、実線
矢印は、物流を表している。物と情報（デマンド情報と
サプライ情報）が図１５に示すように流れている場合、
デマンド情報、サプライ情報において、各矢印の元が
「誰が（Ｗｈｏ）」、矢印の先が「誰に（Ｗｈｏｍ）」
として表現され、指示対象の製品や部品は「何を（Ｗｈ
ａｔ）」、手配や出庫、組配、検査といった指示そのも
のは「どうする（Ｈｏｗ−Ｄｏ）」として表すことがで
きる。

【００７７】これに対して図１６は、リーン生産方式を
導入したプル型の業務形態を示しており、図１５の生産
システムとは全く逆の方式の業務形態を示す。この場
合、計画部門（ＳＢＵ）７１０は、検査部門７３０に対
してだけ指示を出し、それ以外の工程には、後工程から
順次指示が出る。すなわち、計画部門（ＳＢＵ）７１０
からの検査指示発行を受け、検査部門７３０から組配部
門７４０へ組配指示、組配部門７４０からＳＭＴ（表面
実装搭載装置）７５０へ指示、ＳＭＴ７５０から資材部
門７２０へ指示がそれぞれ発行され、計画部門（ＳＢ
Ｕ）は、図１５のような、資材部門との間で手配等、直
接のやりとりは行わない。物と情報（デマンド情報とサ
プライ情報）が図１６に示すように流れている場合で
も、デマンド情報、サプライ情報において、各矢印の元
が「誰が（Ｗｈｏ）」、矢印の先が「誰に（Ｗｈｏ
ｍ）」として表現され、指示対象の製品や部品は「何を
（Ｗｈａｔ）」、手配や出庫、組配、検査といった指示
そのものは「どうする（Ｈｏｗ−Ｄｏ）」として表すこ
とができる。

【００７８】本発明は図１５及び図１６に示されるよう
な任意の生産システムに対して適用可能であり、また、
図１５に示される生産システムを採用していた企業にお
いて、図１６に示すような生産システムに変更する際に
も適用可能である。

【００７９】図１７は、本発明の一実施例のシステム構
成図である。図１７に示すように、本実施例は、Ｕ−Ｒ
ＤＢ（Ｕｎｉｆｉｅｄ Ｒｅｌａｔｉｏｎａｌ Ｄａｔ
ａＢａｓｅ；統合化関係データベース）８０１と呼ばれ
る共有データベースと、共通コンポーネント群８０２
と、業務プロセス及び処理を定義する業務プロセス及び
処理定義群８０３とを備えて構成されている。

【００８０】Ｕ−ＲＤＢ８０１は、デマンド情報及びサ
プライ情報を格納するデマンド／サプライテーブル８１
１、ワークフロー系および在庫系のプロパティを格納す
る汎用プロパティテーブル８１２、デマンド系およびサ
プライ系のプロパティを格納する個別プロパティテーブ
ル８１３の３つのデータベース群からなる。図１との関
係では、Ｕ−ＲＤＢ８０１は共有データベース４に相当
し、デマンド／サプライテーブル８１１はデマンドテー
ブル４３及びサプライテーブル４４に相当し、汎用プロ
パティテーブル８１２及び個別プロパティテーブル８１
３はプロパティテーブル４２に相当する。

【００８１】共通コンポーネント群８０２は、データベ
ース（ＤＢ）検索エンジン８２１、構成展開エンジン８
２２、在庫シミュレーション８２３、オプション処理群
８２４、ＰＯＴ（Ｐｏｒｔａｂｌｅ Ｔｅｒｍｉｎａ
ｌ）／ＢＬＰ（ＢａｒｃｏｄｅＬａｂｅｌ Ｐｒｉｎｔ
ｅｒ）処理群８２５、データベース（ＤＢ）登録更新処
理８２６の６種類のコンポーネント群からなる。ＰＯＴ
は、物流の入出庫業務等で用いられるバーコードリーダ
付きの無線端末であり、ＰＯＴ処理群はこの無線端末と
データ及び制御のやり取りを行うためのソフトウェア処
理要素群よりなり、ＢＬＰはバーコードラベル印刷用の
専用プリンタであり、ＢＬＰ処理群はバーコード印刷用
の専用プリンタとデータ及び制御のやり取りを行うソフ
トウェア処理要素群よりなる。

【００８２】また、業務プロセス及び処理定義群８０３
は、デマンドサプライマスタ８３１、業務手順マスタ８
３２、業務フローマスタ８３３、オプション処理マスタ
８３４の各定義マスタからなる。図１との関係では、デ
マンドサプライマスタ８３１がデマンドサプライマスタ
５１に相当し、業務手順マスタ８３２が業務手順マスタ
５２に相当し、業務フローマスタ８３３が業務フローマ
スタ５３に相当する。オプション処理マスタ８３４は、
情報処理システムに必要とされるオプション処理を定義
するマスタであり、具体的な処理内容はオプション処理
群８２４に記述される。

【００８３】また、実際に業務として運用するには、外
部との連携のため、対人間インタフェース（グラフィカ
ルユーザインタフェース）８０４（各種業務画面等の表
示を行う）と、社内外他システムインタフェース８０５
が設けられる。図１との関係では、対人間インタフェー
ス８０４は、ネットワーク２経由で接続されたクライア
ント端末３のユーザ入出力部３２に相当する。ＰＤＭ
（Ｐｒｏｄｕｃｔｓ Ｄａｔａ Ｍａｎａｇｅｍｅｎ
ｔ）は製品情報管理（製品設計情報管理）を意味してお
り、社内外端末システムインタフェース８０５のＰＤＭ
は、製品の図面／仕様書などの製品設計情報管理システ
ムとのインタフェースである。また、ＣＡＤ／ＣＡＭ／
ＣＡＴは、ＣＡＤ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄ
ｅｓｉｇｎ；計算機支援設計）システム／ＣＡＭ（Ｃｏ
ｍｐｕｔｅｒ Ａｉｄｅｄ Ｍａｎｕｆａｃｔｕｒｅｉ
ｎｇ；計算機設計製造）システム／ＣＡＴ（Ｃｏｍｐｕ
ｔｅｒＡｉｄｅｄ Ｔｅｓｔ；計算機支援試験）システ
ムとのインタフェース、Ｍ／Ｃは工場内での自動化設備
（Ｍ／Ｃ；Ｍａｃｈｉｎｅ）とのインタフェースを表し
ている。

【００８４】対人間インタフェース８０４は、Ｕ−ＲＤ
Ｂ８０１の仕様を参考に、個別業務の形態に合わせ、Ｍ
Ｓ−ＥＸＣＥＬ（商標）、ＭＳ−Ａｃｃｅｓｓ（商標）
等、クライアントの使い慣れたツール／言語を使い容易
かつ自在に作成できる。そして、そのインタフェース部
分は、画面定義やファイル転送内容の編集等であるが、
元になるデータベースが共通のＵ−ＲＤＢ８０１のため
比較的簡単な情報処理であり、適宜変更追加することが
可能であり、クライアント側（エンドユーザ側）でも容
易に作成できる。このため、ＢＰＲや業務改善により、
業務プロセスの変更が必要な際、このインタフェース構
築／変更がネックとなって迅速な対応が損なわれること
にはならない。むしろ、エンドユーザが直接、その都度
対応できるので、ＩＳ（情報システム）部門に依頼し、
バックログとして山積みされ、対応が遅れる弊害から免
れることになる。なお、エンドユーザからＵ−ＲＤＢ８
０１へのアクセスは、後述するトランスファ（Ｔｒａｎ
ｓｆｅｒ）サーバを介して、ＳＱＬ（Ｓｔｒｕｃｔｕｒ
ｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）サーバで行われ
る。

【００８５】次に、本実施例の動作について、図面を参
照して詳細に説明する。

【００８６】生産システムの各作業工程間で受け渡され
る情報は、図１８に示すように、要求／指示９１１Ａ、
実行／実績報告９１１Ｂの２つに分類される。要求／指
示９１１Ａはデマンド情報に、実行／実績報告９１１Ｂ
はサプライ情報に相当する。生産システムの場合、デマ
ンド情報には、受注、出荷指示、発注指示、設計指示、
入庫指示、検査指示、組配指示、出庫指示、購入指示な
どの種類（デマンド種）があり、サプライ情報には、こ
れらのデマンド種に対応して、納入、出荷実績、発注実
績、設計実績、入庫実績、検査実績、組配実績、出庫実
績、購入実績などの種類（デマンド種）がある。本実施
例では、これら全てのデマンド種及びサプライ種の基本
情報を、幾つかのＷと幾つかのＨとで表現してデマンド
／サプライテーブル８１１に登録し、作業工程間で受け
渡す。

【００８７】図１８には、誰が（Ｗｈｏ）、誰に（Ｗｈ
ｏｍ）、いつ（Ｗｈｅｎ）、どこで（Ｗｈｅｒｅ）、何
を（Ｗｈａｔ）の５つのＷと、いくつ（Ｈｏｗ−Ｍａｎ
ｙ）、いつまでに（Ｈｏｗ−Ｌｏｎｇ）、いくらで（Ｈ
ｏｗ−Ｍｕｃｈ）、どうしろ（Ｈｏｗ−Ｄｏ）の４つの
Ｈとで表現する場合を示す。また、この５Ｗと４Ｈで表
現できない個別情報要素は、属性（補完情報）として汎
用プロパティテーブル８１２及び個別プロパティテーブ
ル８１３に登録し、作業工程間で受け渡す。補間情報と
して、図１８には、受注仕様、図面、管理区分、検査結
果、品質情報、予定情報などが示されている。なお、い
つ（Ｗｈｅｎ）、どこに（Ｗｈｅｒｅ）の２つのＷと、
いくつ（Ｈｏｗ−Ｍａｎｙ）、いつまでに（Ｈｏｗ−Ｌ
ｏｎｇ）、いくらで（Ｈｏｗ−Ｍｕｃｈ）の３つのＨと
の、２Ｗと３Ｈは、その何れか１つ又は複数または全部
をなくして、個別情報要素として管理することもでき
る。

【００８８】そして、本実施例においては、システムに
登録できるデマンド種、サプライ種についてデマンドサ
プライマスタ８３１に定義し、また一連の作業工程間の
情報の流れを業務手順マスタ８３２及び業務フローマス
タ８３３に定義しておき、対人間インタフェース８０４
からデマンド情報またはサプライ情報の登録が要求され
たとき、データベース登録更新コンポーネント８２６で
登録の可否をチェックし、情報の受け渡しが事前に定義
された情報の流れの順序通りに行われるように制御して
いる。

【００８９】図１９にデマンドテーブルの内容の一例を
模式的に示す。デマンドテーブルのデータ項目として、
誰が、誰に、何をの３つのＷと、いくつ、いつまでに、
いくらで、どうする（デマンド種）の４つのＨとの汎用
的な名称のデータ項目がある。これらのデータ項目は、
各デマンド種に応じた具体的なデータ項目名称に対応す
る。例えば、受注の場合、誰がは顧客に、誰には受注者
に、何をは受注オーダ、客先注文番号および品名コード
に、いくつは注文数に、いつまでは納期に、いくらは売
価に、どうする（デマンド種）は受注に、それぞれ対応
する。他のデマンド種についても図１９に示すようなデ
ータ項目がそれぞれ対応する。なお、図１９では、何を
のデータ項目中に自キーと親キーとを含めているが、自
キーと親キーとをそれぞれ独立した項目として設けても
良い。

【００９０】図２０は本発明の一実施例による実際の業
務遂行の様子を示す模式図であり、或る通信機製造工場
の生産システムの一部を表している。以下、計画部門と
その関連部門における業務事例に即して説明する。な
お、業務プロセスに関するデマンド／サプライ種と、デ
マンド／サプライ情報の流れは、図１７のデマンドサプ
ライマスタ８３１、業務手順マスタ８３２及び業務フロ
ーマスタ８３３に予め定義されている。

【００９１】計画部門Ａ１の生産手配担当者は、計画に
基づき、製造部門Ａ２への組配指示８１１Ａ４と、必要
資材の手配である購入要求８１１Ａ１を、それぞれデマ
ンド情報としてＵ−ＲＤＢ８０１のデマンドテーブル８
１１Ａに登録する。その際、誰が（Ｗｈｏ）は「計画部
門Ａ１」であり、誰に（Ｗｈｏｍ）はそれぞれ「製造部
門Ａ２」と「購買部門Ａ３」になる。各部門は、自部門
に出されたデマンド情報をＵ−ＲＤＢ８０１のデマンド
テーブル８１１Ａから参照して業務を遂行し、業務を完
了すると、各デマンド情報に対応する「実績」を、Ｕ−
ＲＤＢ８０１のサプライテーブル８１１Ｂにサプライ情
報として登録することで、報告とする。この場合、購入
要求デマンド８１１Ａを受けた購買部門Ａ３は、さらに
取引先Ａ４に対して、購入発注デマンド８１１Ａ２を発
行して注文する。取引先Ａ４が納入すると、納入実績８
１１Ｂ２をサプライ情報として計上し、同時に、購入要
求８１１Ａ１のサプライ情報を、購入実績８１１Ｂ１と
して、サプライテーブル８１１Ｂに登録する。最後に、
計画部門Ａ１は、この実績を受け、物流部門Ａ５に対し
て、入庫指示デマンド８１１Ａ３を発行する。このよう
な流れで、仕事に必要な情報が受け渡されて業務が遂行
される。

【００９２】次に、デマンド情報、サプライ情報の流れ
を定義する業務手順マスタ８３２及び業務フローマスタ
８３３について、図２０に示した業務プロセス事例を業
務手順マスタ８３２と業務フローマスタ８３３に定義し
た状態を模式的に示す図２１を参照して説明する。図２
１において、計画部門Ａ１が発行するデマンド（購入要
求８１１Ａ１と組配指示８１１Ａ４）の手順は、それぞ
れ、９００と９０１で表現される。手順９００では、購
入要求デマンド９００−１を発行し、そのサプライであ
る購入実績サプライ９００−２が計上されると、入庫指
示デマンド９００−３を出し、入庫完了で入庫実績サプ
ライ９００−４を計上するという手順を規定している。
この手順９００の定義情報が、業務手順マスタ８３２に
登録されている。また、購入要求デマンド９００−１を
受けた購入部門Ａ３の購入の手順として、手順９０２が
定義されており、この手順９０２が完了すると、手順９
００の手順に戻っていく流れとなる。この場合の、手順
９００から手順９０２への飛び、手順９０２から手順９
００への戻りの関係を定義したものが、業務フローマス
タ８３３である。

【００９３】次に、本発明の一実施例で用いられるサー
バ環境について、図２２を参照して説明する。各部署に
配置された端末Ｈ２から、実際に各種のデマンド情報お
よびサプライ情報の入力や検索が行われるが、この処理
は、端末からの処理の振り分けを行う仲介サーバとして
機能するトランスファ（Ｔｒａｎｓｆｅｒ）サーバＨ１
に対して、要求種別や検索キーなどを表す処理パラメー
タＨ２−１とデータＨ２−２を送ることで行われる。ト
ランスファサーバＨ１は、端末Ｈ２から送られた処理パ
ラメータＨ２−１及びデータＨ２−２を受け取り、処理
パラメータＨ２−１の要求種別に対応する基幹サーバＨ
３、Ｈ４、Ｈ５や、他のサーバを選択して、処理を実行
させる。ここで、基幹サーバＨ３は、デマンド／サプラ
イテーブル８１１を保持管理するサーバ、基幹サーバＨ
４は、生産ＢＭ等を保持管理するサーバ、基幹サーバＨ
５は、仕様書、図面、ＣＡＤデータ等のプロパティテー
ブル８１２、８１３を保持管理するサーバである。

【００９４】例えば、トランスファサーバＨ１は、デマ
ンド登録処理やサプライ登録処理が要求された場合に
は、基幹サーバＨ３を選択し、ＤＢ登録更新コンポーネ
ント８２６（図１７参照）を実行させ、デマンド情報や
サプライ情報を、デマンド／サプライテーブル８１１
（図１７参照）に登録する。また、受け取った要求が、
検索要求の場合、必要な基幹サーバにＤＢ検索エンジン
８２１を実行させることで検索を行わせる。例えば、受
け取った要求が組配指示情報と組縦図面を検索する場合
には、基幹サーバＨ３に、ＤＢ検索エンジン８２１を実
行させるとともに、図面／仕様書が格納されている基幹
サーバＨ５を選択し、必要な情報を取り出し、端末Ｈ２
に渡す処理を行う。

【００９５】トランスファサーバＨ１は、他システムと
の接続も管理実行する機能を持つ。事例では、表面実装
搭載装置（ＳＭＴ）Ｈ７への作業指示、搭載仕様／実績
収集、他者システムＨ６への情報転送などを行ってい
る。これらの転送情報も、デマンド／サプライの個別プ
ロパティの一種として、個別プロパティテーブル８１３
に登録される。また、トランスファサーバＨ１は、端末
Ｈ２の担当者に構成展開エンジン８２２や在庫シミュレ
ーション８２３等の機能を提供する。

【００９６】次に、図２３を参照して、汎用プロパティ
テーブル８１２及び個別プロパティテーブル８１３につ
いて説明する。汎用プロパティテーブル８１２は、シス
テムとして標準的に備わるプロパティテーブルであり、
ワークフロー系プロパティテーブルと、図２３には図示
していないが在庫系プロパティテーブルとに大別され
る。ワークフロー系プロパティテーブルは、デマンドの
受け渡しやデマンドに対する納期回答情報などの支援を
するためのテーブルである。具体的には、デマンドを受
け付けた側が指定デマンドに対する実行可否判断後に意
思表示を行うためのデマンド受け付けプロパティテーブ
ル、デマンド受けた側が日程および数量の回答（予定入
力）を行うデマンド予定プロパティテーブル、サプライ
入力時にデマンドのキーを取得するための伝票番号情報
を管理する伝票番号制御プロパティテーブルなどがあ
る。

【００９７】他方、個別プロパティテーブル８１３は、
デマンド系プロパティテーブルとサプライ系プロパティ
テーブルとに分類される。デマンド系プロパティテーブ
ルは、品目仕様、購買条件、トップシート、図面製造仕
様、工事仕様ＮＣデータ、試験仕様、出荷仕様などの種
類があり、それぞれ、デマンドテーブルの該当するデマ
ンド情報と関連付けられる。サプライ系プロパティテー
ブルは、検査結果、不具合・品質、入出庫履歴、在庫・
有効、工数・労間、試験データなどの種類があり、それ
ぞれ、サプライテーブルの該当するサプライ情報と関連
付けられる。

【００９８】なお、本発明の一実施例において、社内他
システムや社外他社システムにも、同様のデマンド／サ
プライテーブル及びプロパティテーブルを定義して、当
システムと社内他システムや社外他社システムをトラン
スファサーバＨ１経由で接続し、それらのシステム間で
やり取りされるデマンド情報やサプライ情報をＵ−ＲＤ
Ｂ８０１に登録するようにしてもよい。これは、企業外
システムとの一体化を容易にし、ＳＣＭ（Ｓｕｐｐｌｙ
Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔ）の推進に有効で
あり、また同じ形式のデータベースを共有することで、
仮想的な企業連携活動が可能になる。

【００９９】図２２の事例では、基幹サーバ群Ｈ３〜Ｈ
５と端末Ｈ２の仲介を行うトランスファサーバＨ１を用
いているが、トランスファサーバＨ１を使用せず、端末
Ｈ２と基幹サーバＨ３〜Ｈ５を直接に接続した環境に本
発明を適用することも可能であり、小規模な業務に関し
ては、その環境で実現する場合もある。

【０１００】

【発明の効果】以上説明したように本発明によれば以下
のような効果が得られる。

【０１０１】業務プロセスの変更に対して機敏に変更可
能である。その理由は、業務プロセスを構成する一連の
作業工程間で受け渡される情報を、当該業務プロセスを
構成する一連の作業工程間の情報の流れの順だけでな
く、他の業務プロセスにかかる情報に関連付けて共有デ
ータベースに記憶できるため、業務プロセスの単位を例
えば製品Ａに関連するプロセス、製品Ａを構成する個々
の部品に関連するプロセスといった単位に分割して定義
でき、文献１に記載の従来技術のように互いに関連する
プロセスは１つのプロセスとして一括して定義する場合
に比べて、業務プロセス変更に伴う定義情報の変更箇所
が局所化され、対応が容易になるためである。また、他
の業務プロセスとの関連付けを、用途キーによって行う
ため、互いに相手の情報のコピーを持ち回る場合に比べ
て、重複した情報の記憶が不要となる。

【０１０２】業務プロセスの変更に対してより一層機敏
に変更可能である。その理由は、業務プロセスを構成す
る一連の作業工程間の情報の流れを、一連の作業工程か
らなる単位業務における情報の流れを定義した業務手順
マスタおよび単位業務間の情報の流れを定義した業務フ
ローマスタによって定義しており、業務プロセスの変更
に伴う定義情報の変更箇所が局所化されるためである。
また、共有データベースが、作業工程間で受け渡される
データの情報要素のうち全ての作業工程で共通な共通情
報要素を記憶する共通テーブルと、それ以外の個別情報
要素を記憶するプロパティテーブルとを有しているた
め、共通情報要素以外の個別情報要素が新たに発生した
場合、プロパティテーブルを追加するだけで対処できる
からである。更に、デマンドテーブル及びサプライテー
ブルのデータ項目が、５Ｗ１Ｈ等のように汎用的に使用
できるデータ項目となっているためである。

【０１０３】共有データベースにおける無駄なデータ項
目を削減することができる。その理由は、文献１に記載
の従来技術のように業務プロセスを構成する作業工程に
関連する全てのデータ項目の内容を掲示板データベース
のテーブルに集約すると、作業工程によっては無駄なデ
ータ項目が存在することになるが、作業工程間で受け渡
されるデータの情報要素のうち全ての作業工程で共通な
共通情報要素を記憶する共通テーブルでは、無駄なデー
タ項目がなくなるからである。

【０１０４】業務の現在状況の把握や業務分析をより詳
しく行うことができる。その理由は、仕事の依頼にかか
るデマンド情報だけでなく、依頼された仕事に対する実
績報告にかかるサプライ情報を記録して管理するためで
ある。

【図面の簡単な説明】

【図１】本発明の一実施の形態にかかる業務処理管理シ
ステムの構成図である。

【図２】本発明の一実施の形態にかかる業務処理管理シ
ステムのより詳しい説明を行うために便宜上想定した業
務プロセスのモデルを示す図である。

【図３】デマンドサプライマスタの論理的な構成例を示
す図である。

【図４】業務手順マスタの論理的な構成例を示す図であ
る。

【図５】業務フローマスタの論理的な構成例を示す図で
ある。

【図６】デマンドテーブル及びサプライテーブルのデー
タ項目の一例を示す図である。

【図７】プロパティテーブルの論理的な構成例を示す図
である。

【図８】デマンド情報及びサプライ情報を共有データベ
ースへ登録する際のクライアント端末側及びサーバ側の
処理例を示すフローチャートである。

【図９】サーバの処理部が行う登録可否チェック（Ｓ１
０２）の詳細な処理の一例を示すフローチャートであ
る。

【図１０】デマンド情報及びサプライ情報が一連の作業
工程間の情報の流れの順に関連付けて記憶されている様
子を示す図である。

【図１１】重複登録を求める場合の登録可否チェックの
処理例を示すフローチャートである。

【図１２】重複登録を認めた場合におけるデマンド情報
及びサプライ情報の関連付けの例を示す図である。

【図１３】共有データベースに登録されたデマンド情報
及びサプライ情報を参照する際のクライアント端末側及
びサーバ側の処理例を示すフローチャートである。

【図１４】用途キーによって互いに関連付けられた複数
の業務プロセスの仕事にかかるデマンド情報等を検索し
た際にクライアント端末に表示される内容を模式的に示
す図である。

【図１５】生産システムの一例を示す図である。

【図１６】生産システムの他の例を示す図である。

【図１７】本発明の一実施例のシステム構成図である。

【図１８】生産システムの各作業工程間で受け渡される
情報の説明図である。

【図１９】本発明の一実施例におけるデマンドテーブル
の内容の一例を模式的に示す図である。

【図２０】本発明の一実施例におけるデマンド情報、サ
プライ情報の流れを定義する業務手順マスタ及び業務フ
ローマスタを説明するための業務プロセス事例を示す図
である。

【図２１】図２０に示した業務プロセス事例を業務手順
マスタと業務フローマスタに定義した状態を模式的に示
す図である。

【図２２】本発明の一実施例で用いられるサーバ環境の
構成図である。

【図２３】本発明の一実施例で用いられる汎用プロパテ
ィテーブル及び個別プロパティテーブルの説明図であ
る。

【符号の説明】

１…サーバ ２…ネットワーク ３…クライアント端末 ４…共有データベース ５…業務プロセス定義部 ６…表示装置 ７…入力装置

───────────────────────────────────────────────────── フロントページの続き (72)発明者 安藤 尚志 宮城県黒川郡大和町吉岡字雷神２番地 宮 城日本電気株式会社内 (72)発明者 千葉 英伸 宮城県黒川郡大和町吉岡字雷神２番地 宮 城日本電気株式会社内 (72)発明者 門脇 秀晃 宮城県黒川郡大和町吉岡字雷神２番地 宮 城日本電気株式会社内 Ｆターム(参考） 3C100 AA68 BB04 BB05 BB31 BB36 BB38 BB39 CC01 CC08 CC11

Claims (23)

【特許請求の範囲】
1. 【請求項１】 業務プロセスを構成する複数の作業工程
   間で受け渡される情報及び情報の流れを管理する業務処
   理管理システムであって、 業務プロセスを構成する一連の作業工程間の情報の流れ
   を定義した業務プロセス定義部と、 業務プロセスを構成する一連の作業工程間で受け渡され
   る情報を、当該業務プロセスを構成する一連の作業工程
   間の情報の流れの順および関連する他の業務プロセスに
   関連付けて記憶する共有データベースと、 クライアント端末から前記共有データベースに対する仕
   事に必要な情報の入出力を制御するサーバであって、前
   記業務プロセス定義部に定義された業務プロセスを構成
   する一連の作業工程間の情報の流れ通りの順序で情報が
   入力されるように制御するサーバとを備えたことを特徴
   とする業務処理管理システム。
2. 【請求項２】 前記共有データベースに記憶される情報
   に、自情報を一意に識別するための自キーと、一連の作
   業工程の情報の流れにおける自情報の直前の情報を識別
   するための親キーと、関連する他の業務プロセスの情報
   の自キーの値を持つ用途キーとを備える請求項１記載の
   業務処理管理システム。
3. 【請求項３】 前記業務プロセス定義部は、一連の作業
   工程からなる単位業務における情報の流れを定義した業
   務手順マスタおよび単位業務間の情報の流れを定義した
   業務フローマスタによって、業務プロセスを構成する一
   連の作業工程間の情報の流れを定義するものである請求
   項１または２記載の業務処理管理システム。
4. 【請求項４】 前記共有データベースは、作業工程間で
   受け渡される情報の情報要素のうち全ての作業工程で共
   通な共通情報要素を記憶する共通テーブルと、それ以外
   の個別情報要素を記憶するプロパティテーブルとを有す
   る請求項１または２記載の業務処理管理システム。
5. 【請求項５】 業務プロセスを構成する複数の作業工程
   間で受け渡される情報は、仕事の依頼にかかるデマンド
   情報とその依頼された仕事に対する実績報告にかかるサ
   プライ情報とを含み、前記共通テーブルは、前記デマン
   ド情報を格納するデマンドテーブルと、前記サプライ情
   報を格納するサプライテーブルとで構成される請求項４
   記載の業務処理管理システム。
6. 【請求項６】 前記デマンドテーブル及び前記サプライ
   テーブルは、前記デマンド情報及び前記サプライ情報を
   格納するデータ項目として、少なくとも、誰が（Ｗｈ
   ｏ）に相当する情報要素を格納するデータ項目と、誰に
   （Ｗｈｏｍ）に相当する情報要素を格納するデータ項目
   と、何を（Ｗｈａｔ）に相当する情報要素を格納するデ
   ータ項目と、どうする（Ｈｏｗ−Ｄｏ）に相当する情報
   要素を格納するデータ項目とを備える請求項５記載の業
   務処理管理システム。
7. 【請求項７】 前記デマンドテーブル及び前記サプライ
   テーブルは、前記デマンド情報及び前記サプライ情報を
   格納するデータ項目として、更に、いつ（Ｗｈｅｎ）に
   相当する情報要素を格納するデータ項目、どこに（Ｗｈ
   ｅｒｅ）に相当する情報要素を格納するデータ項目、い
   くつ（Ｈｏｗ−Ｍａｎｙ）に相当する情報要素を格納す
   るデータ項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相当
   する情報要素を格納するデータ項目、いくらで（Ｈｏｗ
   −Ｍｕｃｈ）に相当する情報要素を格納するデータ項目
   のうち、少なくとも１つのデータ項目を備える請求項６
   記載の業務処理管理システム。
8. 【請求項８】 業務プロセスを構成する複数の作業工程
   間で受け渡される情報を記憶する共有データベースと、
   業務プロセスを構成する一連の作業工程間の情報の流れ
   を定義する業務プロセス定義部とに接続されたサーバ、
   及び、前記サーバにネットワーク経由で接続されたクラ
   イアント端末から構成され、業務プロセスを構成する複
   数の作業工程間で受け渡される情報及び情報の流れを管
   理する情報処理システムにおける業務処理管理方法であ
   って、 前記サーバにおいて、クライアント端末から前記共有デ
   ータベースに対する仕事に必要な情報の登録要求時、前
   記業務プロセス定義部に定義された業務プロセスを構成
   する一連の作業工程間の情報の流れ通りの順序であるか
   否かを検査するステップと、 検査がパスしなかった場合に、前記サーバにおいて、前
   記クライアント端末からの要求を拒否するステップと、
   検査がパスした場合に、前記サーバにおいて、登録要求
   された情報を一連の作業工程間の情報の流れの順および
   関連する他の業務プロセスに関連付けて前記共有データ
   ベースに登録するステップとを含む業務処理管理方法。
9. 【請求項９】 前記共有データベースに記憶される情報
   に、自情報を一意に識別するための自キーと、一連の作
   業工程の情報の流れにおける自情報の直前の情報を識別
   するための親キーと、関連する他の業務プロセスの情報
   の自キーの値を持つ用途キーとを付加することにより、
   一連の作業工程間の情報の流れの順および関連する他の
   業務プロセスに関連付ける請求項８記載の業務処理管理
   方法。
10. 【請求項１０】 前記業務プロセス定義部は、一連の作
    業工程からなる単位業務における情報の流れを定義した
    業務手順マスタおよび単位業務間の情報の流れを定義し
    た業務フローマスタによって、業務プロセスを構成する
    一連の作業工程間の情報の流れを定義するものである請
    求項８または９記載の業務処理管理方法。
11. 【請求項１１】 前記共有データベースは、作業工程間
    で受け渡される情報の情報要素のうち全ての作業工程で
    共通な共通情報要素を記憶する共通テーブルと、それ以
    外の個別情報要素を記憶するプロパティテーブルとを有
    する請求項８または９記載の業務処理管理方法。
12. 【請求項１２】 業務プロセスを構成する複数の作業工
    程間で受け渡される情報は、仕事の依頼にかかるデマン
    ド情報とその依頼された仕事に対する実績報告にかかる
    サプライ情報とを含み、前記共通テーブルは、前記デマ
    ンド情報を格納するデマンドテーブルと、前記サプライ
    情報を格納するサプライテーブルとで構成される請求項
    １１記載の業務処理管理方法。
13. 【請求項１３】 前記デマンドテーブル及び前記サプラ
    イテーブルは、前記デマンド情報及び前記サプライ情報
    を格納するデータ項目として、少なくとも、誰が（Ｗｈ
    ｏ）に相当する情報要素を格納するデータ項目と、誰に
    （Ｗｈｏｍ）に相当する情報要素を格納するデータ項目
    と、何を（Ｗｈａｔ）に相当する情報要素を格納するデ
    ータ項目と、どうする（Ｈｏｗ−Ｄｏ）に相当する情報
    要素を格納するデータ項目とを備える請求項１２記載の
    業務処理管理方法。
14. 【請求項１４】 前記デマンドテーブル及び前記サプラ
    イテーブルは、前記デマンド情報及び前記サプライ情報
    を格納するデータ項目として、更に、いつ（Ｗｈｅｎ）
    に相当する情報要素を格納するデータ項目、どこに（Ｗ
    ｈｅｒｅ）に相当する情報要素を格納するデータ項目、
    いくつ（Ｈｏｗ−Ｍａｎｙ）に相当する情報要素を格納
    するデータ項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相
    当する情報要素を格納するデータ項目、いくらで（Ｈｏ
    ｗ−Ｍｕｃｈ）に相当する情報要素を格納するデータ項
    目のうち、少なくとも１つのデータ項目を備える請求項
    １３記載の業務処理管理方法。
15. 【請求項１５】 業務プロセスを構成する複数の作業工
    程間で受け渡される情報を記憶する共有データベース
    と、業務プロセスを構成する一連の作業工程間の情報の
    流れを定義する業務プロセス定義部とに接続されると共
    に、ネットワーク経由でクライアント端末に接続され、
    業務プロセスを構成する複数の作業工程間で受け渡され
    る情報及び情報の流れを管理するサーバ装置であって、 前記クライアント端末から前記共有データベースに対す
    る仕事に必要な情報の登録要求時、前記業務プロセス定
    義部に定義された業務プロセスを構成する一連の作業工
    程間の情報の流れ通りの順序であるか否かを検査する手
    段と、 検査がパスしなかった場合に、前記クライアント端末か
    らの要求を拒否する手段と、 検査がパスした場合に、登録要求された情報を一連の作
    業工程間の情報の流れの順および関連する他の業務プロ
    セスに関連付けて前記共有データベースに登録する手段
    とを含むサーバ装置。
16. 【請求項１６】 前記共有データベースに記憶される情
    報に、自情報を一意に識別するための自キーと、一連の
    作業工程の情報の流れにおける自情報の直前の情報を識
    別するための親キーと、関連する他の業務プロセスの情
    報の自キーの値を持つ用途キーとを付加することによ
    り、一連の作業工程間の情報の流れの順および関連する
    他の業務プロセスに関連付ける手段を備える請求項１５
    記載のサーバ装置。
17. 【請求項１７】 前記業務プロセス定義部は、一連の作
    業工程からなる単位業務における情報の流れを定義した
    業務手順マスタおよび単位業務間の情報の流れを定義し
    た業務フローマスタによって、業務プロセスを構成する
    一連の作業工程間の情報の流れを定義するものである請
    求項１５または１６記載のサーバ装置。
18. 【請求項１８】 前記共有データベースは、作業工程間
    で受け渡される情報の情報要素のうち全ての作業工程で
    共通な共通情報要素を記憶する共通テーブルと、それ以
    外の個別情報要素を記憶するプロパティテーブルとを有
    する請求項１５または１６記載のサーバ装置。
19. 【請求項１９】 業務プロセスを構成する複数の作業工
    程間で受け渡される情報は、仕事の依頼にかかるデマン
    ド情報とその依頼された仕事に対する実績報告にかかる
    サプライ情報とを含み、前記共通テーブルは、前記デマ
    ンド情報を格納するデマンドテーブルと、前記サプライ
    情報を格納するサプライテーブルとで構成される請求項
    １８記載のサーバ装置。
20. 【請求項２０】 前記デマンドテーブル及び前記サプラ
    イテーブルは、前記デマンド情報及び前記サプライ情報
    を格納するデータ項目として、少なくとも、誰が（Ｗｈ
    ｏ）に相当する情報要素を格納するデータ項目と、誰に
    （Ｗｈｏｍ）に相当する情報要素を格納するデータ項目
    と、何を（Ｗｈａｔ）に相当する情報要素を格納するデ
    ータ項目と、どうする（Ｈｏｗ−Ｄｏ）に相当する情報
    要素を格納するデータ項目とを備える請求項１９記載の
    サーバ装置。
21. 【請求項２１】 前記デマンドテーブル及び前記サプラ
    イテーブルは、前記デマンド情報及び前記サプライ情報
    を格納するデータ項目として、更に、いつ（Ｗｈｅｎ）
    に相当する情報要素を格納するデータ項目、どこに（Ｗ
    ｈｅｒｅ）に相当する情報要素を格納するデータ項目、
    いくつ（Ｈｏｗ−Ｍａｎｙ）に相当する情報要素を格納
    するデータ項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相
    当する情報要素を格納するデータ項目、いくらで（Ｈｏ
    ｗ−Ｍｕｃｈ）に相当する情報要素を格納するデータ項
    目のうち、少なくとも１つのデータ項目を備える請求項
    ２０記載のサーバ装置。
22. 【請求項２２】 業務プロセスを構成する複数の作業工
    程間で受け渡される情報を記憶する共有データベース
    と、業務プロセスを構成する一連の作業工程間の情報の
    流れを定義する業務プロセス定義部とに接続されると共
    に、ネットワーク経由でクライアント端末に接続され、
    業務プロセスを構成する複数の作業工程間で受け渡され
    る情報及び情報の流れを管理するサーバを、 前記クライアント端末から前記共有データベースに対す
    る仕事に必要な情報の登録要求時、前記業務プロセス定
    義部に定義された業務プロセスを構成する一連の作業工
    程間の情報の流れ通りの順序であるか否かを検査する手
    段、 検査がパスしなかった場合に、前記クライアント端末か
    らの要求を拒否する手段、 検査がパスした場合に、登録要求された情報を一連の作
    業工程間の情報の流れの順および関連する他の業務プロ
    セスに関連付けて前記共有データベースに登録する手
    段、 として機能させるプログラム。
23. 【請求項２３】 前記サーバを、前記共有データベース
    に記憶される情報に、自情報を一意に識別するための自
    キーと、一連の作業工程の情報の流れにおける自情報の
    直前の情報を識別するための親キーと、関連する他の業
    務プロセスの情報の自キーの値を持つ用途キーとを付加
    することにより、一連の作業工程間の情報の流れの順お
    よび関連する他の業務プロセスに関連付ける手段、とし
    て機能させるプログラムを含む請求項２２記載のプログ
    ラム。