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

Abstract

(57)【要約】 【課題】 業務プロセスの変更に対して情報処理を機敏
に変更可能な業務処理管理システムを提供する。 【解決手段】 業務プロセス定義部５は、業務プロセス
を構成する一連の作業工程間の情報の流れ及びオプショ
ン処理の指定を定義する。共有データベース４は、業務
プロセスを構成する一連の作業工程間で受け渡される情
報を記憶する。サーバ１は、クライアント端末３から共
有データベース４に対する仕事に必要な情報の登録が要
求されると、業務プロセス定義部５に定義された業務プ
ロセスを構成する一連の作業工程間の情報の流れ通りの
順序で情報が入力されるように制御し、且つ、登録、更
新および削除のうちの少なくとも１つの操作種別を対象
として、当該操作種別の操作が行われた情報について業
務プロセス定義部５で定義されたオプション処理の指定
に従ってオプション処理プログラム記憶部８中のオプシ
ョン処理プログラムを実行する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

【０００４】

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

【０００５】それは次の理由による。文献１に記載の従
来技術では、仕事に関する情報に関連して実施すべき情
報処理として作業工程が遷移した旨の通知や処理期限が
迫っている旨の通知を出すなどの業務処理を例示してい
るが、これらの情報処理は複数の作業工程間における情
報の伝達処理を司るプログラムの論理中に組み込まれて
いるため、仕事に関する情報に関連して実施すべき情報
処理の処理内容、処理すべき時期などの変更に多大な時
間と労力が必要となるためである。

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

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

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

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

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

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

【００１２】

【課題を解決するための手段】本発明の第１の業務処理
管理システムは、業務プロセスを構成する複数の作業工
程間で受け渡される情報及び情報の流れ並びに情報処理
を管理する業務処理管理システムであって、業務プロセ
スを構成する一連の作業工程間の情報の流れ及び作業工
程間で受け渡される情報に関連して実施するオプション
処理の指定を定義した業務プロセス定義部と、業務プロ
セスを構成する一連の作業工程間で受け渡される情報
を、当該業務プロセスを構成する一連の作業工程間の情
報の流れの順に関連付けて記憶する共有データベース
と、オプション処理プログラムを記憶するオプション処
理プログラム記憶部と、クライアント端末から前記共有
データベースに対する仕事に必要な情報の登録、更新お
よび削除並びにオプション処理の実行を制御するサーバ
であって、前記業務プロセス定義部に定義された業務プ
ロセスを構成する一連の作業工程間の情報の流れ通りの
順序で情報が登録されるように制御し、且つ、登録、更
新および削除のうちの少なくとも１つの操作種別を対象
として、当該操作種別の操作が行われた情報について前
記業務プロセス定義部で定義されたオプション処理の指
定に従って前記オプション処理プログラム記憶部中のオ
プション処理プログラムを実行するサーバとを備えてい
る。より具体的には、前記業務プロセス定義部は、作業
工程間で受け渡される情報を一意に識別する情報、その
情報に関連して実施するオプション処理を一意に識別す
るオプション処理名、そのオプション処理を実施する条
件となる当該情報にかかる操作種別及びそのオプション
処理を実施するタイミングの指定を定義したオプション
処理マスタを含んで構成され、また、前記共有データベ
ースに記憶される情報に、自情報を一意に識別するため
の自キーと、一連の作業工程の情報の流れにおける自情
報の直前の情報を識別するための親キーとを備える。

【００１３】本発明の第２の業務処理管理システムは、
第１の業務処理管理システムにおいて、前記共有データ
ベースは、業務プロセスを構成する一連の作業工程間で
受け渡される情報を、当該業務プロセスを構成する一連
の作業工程間の情報の流れの順および関連する他の業務
プロセスに関連付けて記憶するものとして構成される。
より具体的には、前記共有データベースに記憶される情
報に、自情報を一意に識別するための自キーと、一連の
作業工程の情報の流れにおける自情報の直前の情報を識
別するための親キーと、関連する他の業務プロセスの情
報の自キーの値を持つ用途キーとを備える。

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

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

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

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

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

【００１９】本発明の第１の業務処理管理方法は、業務
プロセスを構成する複数の作業工程間で受け渡される情
報を記憶する共有データベースと、業務プロセスを構成
する一連の作業工程間の情報の流れ及び作業工程間で受
け渡される情報に関連して実施するオプション処理の指
定を定義する業務プロセス定義部とに接続されたサー
バ、及び、前記サーバにネットワーク経由で接続された
クライアント端末から構成され、業務プロセスを構成す
る複数の作業工程間で受け渡される情報及び情報の流れ
並びに情報処理を管理する情報処理システムにおける業
務処理管理方法であって、前記サーバにおいて、前記業
務プロセス定義部に定義された業務プロセスを構成する
一連の作業工程間の情報の流れ通りの順序で情報が登録
されるように制御するステップと、登録、更新および削
除のうちの少なくとも１つの操作種別を対象として、当
該操作種別の操作が行われた情報について前記業務プロ
セス定義部で定義されたオプション処理の指定に従って
前記オプション処理プログラム記憶部中のオプション処
理プログラムを実行するステップとを含んでいる。より
具体的には、前記業務プロセス定義部は、作業工程間で
受け渡される情報を一意に識別する情報、その情報に関
連して実施するオプション処理を一意に識別するオプシ
ョン処理名、そのオプション処理を実施する条件となる
当該情報にかかる操作種別及びそのオプション処理を実
施するタイミングの指定を定義したオプション処理マス
タを含み、前記共有データベースに記憶される情報に、
自情報を一意に識別するための自キーと、一連の作業工
程の情報の流れにおける自情報の直前の情報を識別する
ための親キーとを付加することにより、一連の作業工程
間の情報の流れの順に情報を関連付ける。

【００２０】本発明の第２の業務処理管理方法は、第１
の業務処理管理方法において、前記共有データベース
は、業務プロセスを構成する一連の作業工程間で受け渡
される情報を、当該業務プロセスを構成する一連の作業
工程間の情報の流れの順および関連する他の業務プロセ
スに関連付けて記憶するようにしている。より具体的に
は、前記共有データベースに記憶される情報に、自情報
を一意に識別するための自キーと、一連の作業工程の情
報の流れにおける自情報の直前の情報を識別するための
親キーと、関連する他の業務プロセスの情報の自キーの
値を持つ用途キーとを付加することにより、一連の作業
工程間の情報の流れの順および関連する他の業務プロセ
スに関連付ける。

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

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

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

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

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

【００２６】

【作用】第１の業務処理管理システム及び方法にあって
は、業務プロセスを構成する一連の作業工程間の情報の
流れ及び作業工程間で受け渡される情報に関連して実施
するオプション処理の指定を業務プロセス定義部に定義
してあり、サーバでは、クライアント端末から出力され
た業務プロセスを構成する作業工程間で受け渡される情
報を定義された流れ通りに共有データベースに登録する
と共に、登録、更新および削除のうちの少なくとも１つ
の操作種別を対象として、当該操作種別の操作が行われ
た情報について業務プロセス定義部で定義されたオプシ
ョン処理の指定に従ってオプション処理プログラム記憶
部中のオプション処理プログラムを実行するため、オプ
ション処理の指定の変更は業務プロセス定義部中のオプ
ション処理の指定の変更で対処することができる。この
ため、業務プロセスの変更に伴うオプション処理の指定
の変更、つまり一連の作業工程間で受け渡される情報に
関する情報処理の変更を簡便に実施することが可能とな
る。特に、作業工程間で受け渡される情報を一意に識別
する情報、その情報に関連して実施するオプション処理
を一意に識別するオプション処理名、そのオプション処
理を実施する条件となる当該情報にかかる操作種別及び
そのオプション処理を実施するタイミングの指定をオプ
ション処理マスタで定義する構成にあっては、どのよう
な情報が、どのように操作されたときに、どのようなタ
イミングでオプション処理を実行するのかをきめ細かく
制御でき、且つ、その変更もオプション処理マスタの更
新で行える。また、オプション処理プログラムは独立し
たプログラムとしてオプション処理プログラム記憶部に
記憶されており、オプション処理の内容の変更もオプシ
ョン処理プログラム記憶部の変更で対処することができ
る。

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

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

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

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

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

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

【００３３】

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

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

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

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

【００３７】オプション処理マスタ５４は、デマンド情
報及びサプライ情報の操作時に同時に実行されるオプシ
ョン処理の指定を定義するマスタファイルである。ここ
で、操作とは、登録、更新、削除の何れか１つ、または
複数、または全てを意味する。このオプション処理マス
タ５４では、どのようなデマンド種、サプライ種が、ど
う操作されたときに、どのタイミングで、どのオプショ
ン処理を実行するかが定義されており、オプション処理
を実行するプログラム自体はオプション処理プログラム
記憶部８に記憶されている。どのタイミングとは、操作
前のタイミング、操作後のタイミングの何れかを意味す
る。各種の業務ファイル９は、オプション処理の対象と
なるデータを記憶するファイルであり、その種類と数は
本実施の形態にかかる業務処理管理システムの適用分野
およびオプション処理の内容によって決定される。

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

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

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

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

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

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

【００４４】サーバ１の処理部１２は、クライアント端
末３からの要求に従って共有データベース４に対するデ
ータの入出力を制御すると共にオプション処理の実行を
制御する制御部である。サーバ１の通信制御部１３は、
ネットワーク２を介してクライアント端末３との間に行
われるデータ等の送受信を制御する部分である。

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

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

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

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

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

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

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

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

【００５３】図６はオプション処理マスタ５４の論理的
な構成例を示す。図６に示すように、オプション処理マ
スタ５４には、作業工程間で受け渡されるデマンド情報
やサプライ情報のうちオプション処理が必要となるもの
毎に、手順区分５４−１、デマンド／サプライ種５４−
２、更新区分５４−３、処理区分５４−４およびオプシ
ョン処理名５４−５がそれぞれのレコードＲ４１〜Ｒ４
８に定義される。オプション処理名５４−５は実行すべ
きオプション処理プログラムを一意に識別する識別子で
ある。手順区分５４−１およびデマンド／サプライ種５
４−２は作業工程間で受け渡される情報を一意に識別す
る情報であり、当該オプション処理を実行する単位業務
およびデマンド／サプライ種を指定するものである。更
新区分５４−３は当該オプション処理を当該デマンド／
サプライ種の登録、更新、削除の何れの操作時に実行す
べきかを指定するもので、Ｉは登録時、Ｕは更新時、Ｄ
は削除時をそれぞれ示す。処理区分５４−４は、当該オ
プション処理を操作前に実行すべきか、操作後に実行す
べきかを指定するもので、ＡＦは操作後に実行すべきこ
とを、ＢＦは操作前に実行すべきことをそれぞれ示す。
図２のモデルの場合、単位業務Ｘ及び単位業務Ｙにはデ
マンド種Ｄ１、サプライ種Ｓ１についてオプション処理
ＯＰ００１、ＯＰ００２があり、単位業務Ｚにはデマン
ド種Ｄ２、サプライ種Ｓ２についてオプション処理ＯＰ
００３、ＯＰ００４〜ＯＰ００６があるため、それらに
ついて図６に示されるように定義されている。

【００５４】例えばレコードＲ４１は、単位業務Ｘにお
けるデマンド種Ｄ１の登録時、その登録後にオプション
処理名ＯＰ００１のオプション処理を実行することを定
義している。またレコードＲ４７は、単位業務Ｚにおけ
るサプライ種Ｓ２の削除時、その削除前にオプション処
理名ＯＰ０００５のオプション処理を実行することを定
義している。なお、デマンド種およびサプライ種の登録
時のみなど、特定の操作時にのみオプション処理を実行
する場合には更新区分５４−３は省略して良い。また、
操作前、操作後の何れか一方でのみオプション処理を実
行する場合、処理区分５４−４は省略して良い。

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

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

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

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

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

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

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

【００６２】他方、登録可能と判断した場合（ステップ
Ｓ１０３でＹＥＳ）、処理部１２は、登録前オプション
処理の指定が定義されているかどうかを調べる（ステッ
プＳ１０５）。具体的には、登録要求されたデマンド情
報またはサプライ情報のデータ項目４３−９または４４
−９に設定された手順区分とデマンド／サプライ種をキ
ーに図６のオプション処理マスタ５４を検索してオプシ
ョン処理の指定の有無を調べ、指定があれば、さらに更
新区分５４−３がＩ（すなわち登録時）で且つ処理区分
５４−４がＢＦ（すなわち登録前）になっているかどう
かで、登録前オプション処理の指定が定義されているか
どうかを調べる。そして、登録前オプション処理の指定
が定義されていた場合には、オプション処理名５４−５
に該当するオプション処理プログラムをオプション処理
プログラム記憶部８から読み出して実行する（ステップ
Ｓ１０６）。登録前オプション処理の指定が定義されて
いなければ、ステップＳ１０６はスキップする。

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

【００６４】次に、処理部１２は、登録後オプション処
理の指定が定義されているかどうかを調べる（ステップ
Ｓ１０８）。具体的には、登録したデマンド情報または
サプライ情報のデータ項目４３−９または４４−９に設
定された手順区分とデマンド／サプライ種をキーに図６
のオプション処理マスタ５４を検索してオプション処理
の指定の有無を調べ、指定があれば、さらに更新区分５
４−３がＩ（すなわち登録時）で且つ処理区分５４−４
がＡＦ（すなわち登録後）になっているかどうかで、登
録後オプション処理の指定が定義されているかどうかを
調べる。そして、登録後オプション処理の指定が定義さ
れていた場合には、オプション処理名５４−５に該当す
るオプション処理プログラムをオプション処理プログラ
ム記憶部８から読み出して実行する（ステップＳ１０
９）。登録後オプション処理の指定が定義されていなけ
れば、ステップＳ１０９はスキップする。

【００６５】サーバ１の処理部１２は、以上のようにし
てデマンド情報またはサプライ情報の共有データベース
４への登録処理を終えると、その旨を要求元のクライア
ント端末３へ通知する（ステップＳ１１０）。

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７９】共有データベース４に登録されたデマンド
情報およびサプライ情報を更新する際の処理の流れは基
本的には図９と同じである。但し、ステップＳ３０１で
は更新後のデマンド情報等を設定した入力用テーブルが
作成され、ステップＳ３０２ではサーバ１へ更新要求が
出される。また、サーバ側の更新可否チェックＳ１０２
では、更新対象となるデマンド情報またはサプライ情報
が実際に存在するかがチェックされる。更に、ステップ
Ｓ１０５では、更新要求されたデマンド情報またはサプ
ライ情報のデータ項目４３−９または４４−９に設定さ
れた手順区分とデマンド／サプライ種をキーに図６のオ
プション処理マスタ５４を検索してオプション処理の指
定の有無を調べ、指定があれば、さらに更新区分５４−
３がＵ（すなわち更新時）で且つ処理区分５４−４がＢ
Ｆ（すなわち登録前）になっているかどうかで、更新前
オプション処理の指定が定義されているかどうかを調べ
る。そして、更新前オプション処理の指定が定義されて
いた場合には、ステップＳ１０６において、オプション
処理名５４−５に該当するオプション処理プログラムを
オプション処理プログラム記憶部８から読み出して実行
する。ステップＳ１０７では、更新要求されたデマンド
情報またはサプライ情報で元のデマンド情報またはサプ
ライ情報を更新する。また、ステップＳ１０８では、更
新したデマンド情報またはサプライ情報のデータ項目４
３−９または４４−９に設定された手順区分とデマンド
／サプライ種をキーに図６のオプション処理マスタ５４
を検索してオプション処理の指定の有無を調べ、指定が
あれば、さらに更新区分５４−３がＵ（すなわち更新
時）で且つ処理区分５４−４がＡＦ（すなわち登録後）
になっているかどうかで、更新後オプション処理の指定
が定義されているかどうかを調べる。そして、更新後オ
プション処理の指定が定義されていた場合には、ステッ
プＳ１０９において、オプション処理名５４−５に該当
するオプション処理プログラムをオプション処理プログ
ラム記憶部８から読み出して実行する。

【００８０】共有データベース４に登録されたデマンド
情報およびサプライ情報を削除する際の処理の流れも基
本的には図９と同じであるが、入力用テーブルは必要な
く、クライアント端末３からサーバ１へ削除するデマン
ド情報またはサプライ情報を特定する情報（例えば自キ
ーなど）を指定して削除を要求する。サーバ１では、削
除対象となるデマンド情報またはサプライ情報が実際に
存在するか否かをチェックし、存在していれば削除す
る。削除前オプション処理の有無判定では、削除要求さ
れたデマンド情報またはサプライ情報のデータ項目４３
−９または４４−９に設定された手順区分とデマンド／
サプライ種をキーに図６のオプション処理マスタ５４を
検索してオプション処理の指定の有無を調べ、指定があ
れば、さらに更新区分５４−３がＤ（すなわち削除時）
で且つ処理区分５４−４がＢＦ（すなわち登録前）にな
っているかどうかで、削除前オプション処理の指定が定
義されているかどうかを調べる。そして、削除前オプシ
ョン処理の指定が定義されていた場合には、オプション
処理名５４−５に該当するオプション処理プログラムを
オプション処理プログラム記憶部８から読み出して実行
する。削除後オプション処理の有無判定では、削除した
デマンド情報またはサプライ情報のデータ項目４３−９
または４４−９に設定された手順区分とデマンド／サプ
ライ種をキーに図６のオプション処理マスタ５４を検索
してオプション処理の指定の有無を調べ、指定があれ
ば、さらに更新区分５４−３がＤ（すなわち削除時）で
且つ処理区分５４−４がＡＦ（すなわち削除後）になっ
ているかどうかで、削除後オプション処理の指定が定義
されているかどうかを調べる。そして、削除後オプショ
ン処理の指定が定義されていた場合には、オプション処
理名５４−５に該当するオプション処理プログラムをオ
プション処理プログラム記憶部８から読み出して実行す
る。

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

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

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

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

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

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

【００８７】

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

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

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

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

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

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

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

【００９４】また、業務プロセス及び処理定義群８０３
は、デマンドサプライマスタ８３１、業務手順マスタ８
３２、業務フローマスタ８３３、オプション処理マスタ
８３４の各定義マスタからなる。図１との関係では、デ
マンドサプライマスタ８３１がデマンドサプライマスタ
５１に相当し、業務手順マスタ８３２が業務手順マスタ
５２に相当し、業務フローマスタ８３３が業務フローマ
スタ５３に相当し、オプション処理マスタ８３４がオプ
ション処理マスタ５４に相当する。

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

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

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

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

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

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

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

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

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

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

【０１０５】図２３は本発明の一実施例によるオプショ
ン処理の実行例を示す模式図であり、（ａ）は庫材出庫
デマンド登録時のオプション処理例を、（ｂ）は庫材出
庫実績サプライ登録時のオプション処理例をそれぞれ示
す。

【０１０６】図２３（ａ）では、庫材出庫デマンド１０
０１のデマンドテーブル１００２への登録時、オプショ
ン処理マスタ８３４で定義された指定に従ってオプショ
ン処理として有効在庫計算処理１００３が実行され、Ｂ
Ｍプロパティ（部品構成表）１００４を参照して、庫材
出庫デマンド１００１の内容に基づいて有効在庫マスタ
１００５を自動的に更新している。

【０１０７】図２３（ｂ）では、庫材出庫実績サプライ
１０１１のサプライテーブル１０１２への登録時、オプ
ション処理マスタ８３４で定義された指定に従ってオプ
ション処理として在庫数計算処理１０１３が実行され、
庫材出庫実績サプライ１０１１の内容に基づいて在庫数
マスタ１０１４を自動的に更新している。

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

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

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

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

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

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

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

【０１１５】

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

【０１１６】業務プロセスの変更に対して機敏に変更可
能である。その理由は、オプション処理の指定の変更は
業務プロセス定義部中のオプション処理の指定の変更で
対処することができ、オプション処理の内容はオプショ
ン処理プログラム記憶部の変更で対処することができ、
一連の作業工程間で受け渡される情報に関する情報処理
の変更を簡便に実施することができるからである。特
に、作業工程間で受け渡される情報を一意に識別する情
報、その情報に関連して実施するオプション処理を一意
に識別するオプション処理名、そのオプション処理を実
施する条件となる当該情報にかかる操作種別及びそのオ
プション処理を実施するタイミングの指定をオプション
処理マスタで定義する構成にあっては、どのような情報
が、どのように操作されたときに、どのようなタイミン
グでオプション処理を実行するのかをきめ細かく制御で
き、且つ、その変更もオプション処理マスタの更新で行
える。

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

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

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

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

【図面の簡単な説明】

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

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

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

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

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

【図６】オプション処理マスタの論理的な構成例を示す
図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図２３】本発明の一実施例によるオプション処理の実
行例を示す模式図である。

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

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

【符号の説明】

１…サーバ ２…ネットワーク ３…クライアント端末 ４…共有データベース ５…業務プロセス定義部 ６…表示装置 ７…入力装置 ８…オプション処理プログラム記憶部 ９…各種の業務ファイル

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

Claims (32)

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