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

Description

【０００１】
【発明の属する技術分野】
本発明は生産管理や販売・物流などにかかる業務処理をコンピュータによって管理する技術に関し、特に業務担当者間で受け渡される情報及び情報の流れ並びに各種の情報処理をコンピュータによって管理するシステム及びその方法に関する。
【０００２】
【従来の技術】
一般に企業等における業務プロセスは、複数の作業工程の一連の流れで構成され、仕事に必要な情報が作業工程間で適宜伝達されることにより業務が遂行される。このような仕事に必要な情報の伝達をコンピュータによって管理する場合、業務プロセスを構成する複数の作業工程間の情報の流れを如何にして管理するか、或る作業工程から次の作業工程へ受け渡される仕事に関する情報を如何にして管理するか、関連する仕事どうしを如何に関連付けるか、仕事に関する情報に関連して実施すべき情報処理を如何にして実現するかが重要である。
【０００３】
複数の作業工程間における情報の伝達をコンピュータによって管理する技術の一例が特開平１０−２１４１１３号公報（以下、文献１と称す）に示されている。この文献１に記載された従来技術では、業務プロセスを構成する複数の作業工程のシーケンスを、各作業工程に１対１に対応付けたレコードを工程順に並べた状態遷移ルールによって定義し、更に各レコードにおいて当該作業工程でデータ入力を完了すべきデータ項目を定義する。また、業務プロセスを構成する作業工程に関連する全てのデータ項目の内容を掲示板データベースのテーブルに集約し、関連する全ての担当者がこのデータベースを掲示板の形式で共有することにより、作業工程間で授受されるデータを管理する。掲示板データベースは、少なくとも１組の掲示板データを保持する。１組の掲示板データは業務処理システム上で処理される個々の一連の業務に対応して形成される。掲示板データベースはまた、現在作業中の状態にある作業工程も管理する。コンピュータは、掲示板データベース及び状態遷移ルールを参照して、原則として現在作業中の工程に関するデータのみを受け付けることで、作業工程間の情報の流れが事前に定義された順序通りになるように制御する。またコンピュータは、作業工程の遷移が可能と判断したときに新たに作業を行うことが可能となった作業工程の作業を行う担当者の端末装置へ作業工程が遷移した旨の通知を出したり、処理期限のある作業工程についてその作業工程の作業を行う担当者の端末装置に期限が迫っている旨の通知を出したりする各種の情報処理を実施する。
【０００４】
【発明が解決しようとする課題】
近年、激変する事業環境の影響を受け、頻繁に実施されるＢＰＲ（Business Process Reengineering；ビジネスプロセスリエンジニアリング）や、生産の現場で日々行われる「カイゼン」と呼ばれる小集団活動による業務プロセスの変化に合わせて、業務処理管理システムを機敏に変更させる必要性が強く望まれている。特に、ハイテク企業の生産システムにおいては、商品のライフサイクルの短命化とあわせ、日々が業務プロセスの変化の連続であり、今後、この傾向は一層強まる状況にあるため、業務処理管理システムの対応の遅れは、プロセス改善の足かせとなる。しかるに文献１に記載の従来技術では、業務プロセスの変更に機敏に対応することが容易でないという課題がある。
【０００５】
それは次の理由による。文献１に記載の従来技術では、仕事に関する情報に関連して実施すべき情報処理として作業工程が遷移した旨の通知や処理期限が迫っている旨の通知を出すなどの業務処理を例示しているが、これらの情報処理は複数の作業工程間における情報の伝達処理を司るプログラムの論理中に組み込まれているため、仕事に関する情報に関連して実施すべき情報処理の処理内容、処理すべき時期などの変更に多大な時間と労力が必要となるためである。
【０００６】
文献１に記載の従来技術が業務プロセスの変更に機敏に対応することが容易でない別の理由は、文献１に記載の従来技術は、業務プロセス毎にそれを構成する全ての作業工程の流れを一連の流れとして状態遷移ルールによって定義することで作業工程間の情報の流れを管理しているため、複数の業務プロセスで共通に使われる作業工程に変更があったとき、変更すべき状態遷移ルールが多岐にわたり、変更に多大な時間と労力が必要となるためである。例えば、作業工程ｋ１→作業工程ｋ２→作業工程ｋ３から構成される一連の作業工程を全ての業務プロセスが含む場合、従来技術では、各業務プロセスの作業工程の流れの定義中に、「作業工程ｋ１→作業工程ｋ２→作業工程ｋ３」の定義が含まれるため、業務改善などにより当該一連の作業工程が「作業工程ｋ１→作業工程ｋ３」に変更されると、全業務プロセスの作業工程の定義を修正する必要がある。
【０００７】
文献１に記載の従来技術が業務プロセスの変更に機敏に対応することが容易でない更に別の理由は、一連の業務プロセスに関連する全てのデータ項目の内容を掲示板データベースのテーブルに格納しているため、或る業務プロセスの変更によって既存の掲示板データベースに存在しないデータ項目が必要となった場合、そのようなデータ項目を必要とする業務プロセスがほんの一部のプロセスであっても、新たなデータ項目をデータベースのテーブルへ追加する必要があり、そのための大掛かりな作業が必要になるためである。
【０００８】
文献１に記載の従来技術が業務プロセスの変更に機敏に対応できない他の理由として、以下の理由がある。従来技術では、掲示板データベースにおいて関連付けて記憶することができる情報は、個々の掲示板データを構成する情報どうし、つまり状態遷移ルールによって定義された業務プロセスを構成する複数の作業工程のシーケンスにかかわる一連のデータどうしに限られ、異なる掲示板データどうし、つまり業務プロセスどうしは関連付けることはできない。これは、関連する仕事は１つの掲示板データに集約し、必要な全ての情報の流れを１つの掲示板データで管理しなければならないことを意味する。従って、或る製品Ａを部品ａ１、ａ２から製造する生産システムを考えた場合、製品Ａに関連する一連の作業工程および部品ａ１、ａ２に関連する一連の作業工程を全て含む一連の作業工程を事前に定義し、この一連の作業工程の情報の流れを１組の掲示板データで管理する必要がある。このため、製品Ａ、部品ａ１、ａ２の何れかの一連の作業工程が変更されると、他の部品や製品の作業工程に影響がなくても、定義した一連の作業工程全体の再定義が必要になり、その変更に多大な時間と労力が必要となる。
【０００９】
また、文献１に記載の従来技術では、各担当者から掲示板データベースに入力されたデータの履歴を記録しており、必要に応じて入力済のデータを参照することで、業務の現在の状況や業務分析等が或る程度は行えるようになっている。しかし、掲示板データベースに入力されるデータは、主に仕事の依頼に関するデータに限定されており、依頼に対する実績報告が必ずしも記録されていないために充分な現状把握や業務分析は行えないという課題もある。
【００１０】
本発明はこのような事情に鑑みて提案されたものであり、その目的は、業務プロセスの変更に対して機敏に変更可能な業務処理管理システム及びその方法を提供することにある。
【００１１】
本発明の別の目的は、業務の現在状況の把握や業務分析をより詳しく行うことができる業務処理管理システム及びその方法を提供することにある。
【００１２】
【課題を解決するための手段】
本発明の第１の業務処理管理システムは、業務プロセスを構成する複数の作業工程間で受け渡される情報及び情報の流れ並びに情報処理を管理する業務処理管理システムであって、
一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド／サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド／サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド／サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド／サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義し、かつ、作業工程間で受け渡される情報のうちオプション処理が必要となる情報毎に、その情報の種別を示すデマンド／サプライ種と業務単位を示す手順区分、その情報に関連して実施するオプション処理を一意に識別するオプション処理名、そのオプション処理を実施する条件となる当該情報にかかる操作種別及びそのオプション処理を実施するタイミングの指定を定義したオプション処理マスタを記憶する業務プロセス定義部と、
作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーとを持つ情報を記憶する共有データベースと、
オプション処理名に対応するオプション処理プログラムを記憶するオプション処理プログラム記憶部と、
クライアント端末から前記共有データベースに対する仕事に必要な情報の登録、更新および削除並びにオプション処理の実行を制御するサーバであって、前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド／サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド／サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御し、且つ、登録、更新および削除のうちの少なくとも１つの操作種別を対象として、当該操作種別の操作が行われた情報の種別を示すデマンド／サプライ種と業務単位を示す手順区分をキーに前記オプション処理マスタを検索してオプション処理の指定の有無を調べ、オプション処理の指定があり且つオプション処理を実施する条件ならびにオプション処理を実施するタイミングが成立していることを条件に前記オプション処理プログラム記憶部中の該当するオプション処理プログラムを実行するサーバとを備えたことを特徴とする。
【００１３】
本発明の第２の業務処理管理システムは、第１の業務処理管理システムにおいて、前記共有データベースは、業務プロセスを構成する一連の作業工程間で受け渡される情報を、当該業務プロセスを構成する一連の作業工程間の情報の流れの順および関連する他の業務プロセスに関連付けて記憶するものとして構成される。より具体的には、前記共有データベースに記憶される情報に、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを備える。
【００１５】
本発明の第３の業務処理管理システムは、第１または第２の業務処理管理システムにおいて、前記共有データベースは、作業工程間で受け渡される情報の情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有する。
【００１６】
本発明の第４の業務処理管理システムは、第３の業務処理管理システムにおいて、業務プロセスを構成する複数の作業工程間で受け渡される情報は、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、前記共通テーブルは、前記デマンド情報を格納するデマンドテーブルと、前記サプライ情報を格納するサプライテーブルとで構成される。
【００１７】
本発明の第５の業務処理管理システムは、第４の業務処理管理システムにおいて、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、少なくとも、誰が（Ｗｈｏ）に相当する情報要素を格納するデータ項目と、誰に（Ｗｈｏｍ）に相当する情報要素を格納するデータ項目と、何を（Ｗｈａｔ）に相当する情報要素を格納するデータ項目と、どうする（Ｈｏｗ−Ｄｏ）に相当する情報要素を格納するデータ項目とを備える。
【００１８】
本発明の第６の業務処理管理システムは、第５の業務処理管理システムにおいて、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、更に、いつ（Ｗｈｅｎ）に相当する情報要素を格納するデータ項目、どこに（Ｗｈｅｒｅ）に相当する情報要素を格納するデータ項目、いくつ（Ｈｏｗ−Ｍａｎｙ）に相当する情報要素を格納するデータ項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相当する情報要素を格納するデータ項目、いくらで（Ｈｏｗ−Ｍｕｃｈ）に相当する情報要素を格納するデータ項目のうち、少なくとも１つのデータ項目を備える。
【００１９】
本発明の第１の業務処理管理方法は、一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド／サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド／サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド／サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド／サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義し、かつ、作業工程間で受け渡される情報のうちオプション処理が必要となる情報毎に、その情報の種別を示すデマンド／サプライ種と業務単位を示す手順区分、その情報に関連して実施するオプション処理を一意に識別するオプション処理名、そのオプション処理を実施する条件となる当該情報にかかる操作種別及びそのオプション処理を実施するタイミングの指定を定義したオプション処理マスタを記憶する業務プロセス定義部と、作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーとを持つ情報を記憶する共有データベースと、オプション処理名に対応するオプション処理プログラムを記憶するオプション処理プログラム記憶部と、クライアント端末から前記共有データベースに対する仕事に必要な情報の登録、更新および削除並びにオプション処理の実行を制御するサーバと、前記サーバにネットワーク経由で接続されたクライアント端末とから構成され、業務プロセスを構成する複数の作業工程間で受け渡される情報及び情報の流れ並びに情報処理を管理する情報処理システムにおける業務処理管理方法であって、前記サーバにおいて、前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド／サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド／サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御するステップと、登録、更新および削除のうちの少なくとも１つの操作種別を対象として、当該操作種別の操作が行われた情報の種別を示すデマンド／サプライ種と業務単位を示す手順区分をキーに前記オプション処理マスタを検索してオプション処理の指定の有無を調べ、オプション処理の指定があり且つオプション処理を実施する条件ならびにオプション処理を実施するタイミングが成立していることを条件に前記オプション処理プログラム記憶部中の該当するオプション処理プログラムを実行するステップとを含んでいる。
【００２０】
本発明の第２の業務処理管理方法は、第１の業務処理管理方法において、前記共有データベースは、業務プロセスを構成する一連の作業工程間で受け渡される情報を、当該業務プロセスを構成する一連の作業工程間の情報の流れの順および関連する他の業務プロセスに関連付けて記憶するようにしている。より具体的には、前記共有データベースに記憶される情報に、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを付加することにより、一連の作業工程間の情報の流れの順および関連する他の業務プロセスに関連付ける。
【００２２】
本発明の第３の業務処理管理方法は、第１または第２の業務処理管理方法において、前記共有データベースは、作業工程間で受け渡される情報の情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有する。
【００２３】
本発明の第４の業務処理管理方法は、第３の業務処理管理方法において、業務プロセスを構成する複数の作業工程間で受け渡される情報は、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、前記共通テーブルは、前記デマンド情報を格納するデマンドテーブルと、前記サプライ情報を格納するサプライテーブルとで構成される。
【００２４】
本発明の第５の業務処理管理方法は、第４の業務処理管理方法において、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、少なくとも、誰が（Ｗｈｏ）に相当する情報要素を格納するデータ項目と、誰に（Ｗｈｏｍ）に相当する情報要素を格納するデータ項目と、何を（Ｗｈａｔ）に相当する情報要素を格納するデータ項目と、どうする（Ｈｏｗ−Ｄｏ）に相当する情報要素を格納するデータ項目とを備える。
【００２５】
本発明の第６の業務処理管理方法は、第５の業務処理管理方法において、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、更に、いつ（Ｗｈｅｎ）に相当する情報要素を格納するデータ項目、どこに（Ｗｈｅｒｅ）に相当する情報要素を格納するデータ項目、いくつ（Ｈｏｗ−Ｍａｎｙ）に相当する情報要素を格納するデータ項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相当する情報要素を格納するデータ項目、いくらで（Ｈｏｗ−Ｍｕｃｈ）に相当する情報要素を格納するデータ項目のうち、少なくとも１つのデータ項目を備える。
【００２６】
【作用】
第１の業務処理管理システム及び方法にあっては、業務プロセスを構成する一連の作業工程間の情報の流れ及び作業工程間で受け渡される情報に関連して実施するオプション処理の指定を業務プロセス定義部に定義してあり、サーバでは、クライアント端末から出力された業務プロセスを構成する作業工程間で受け渡される情報を定義された流れ通りに共有データベースに登録すると共に、登録、更新および削除のうちの少なくとも１つの操作種別を対象として、当該操作種別の操作が行われた情報について業務プロセス定義部で定義されたオプション処理の指定に従ってオプション処理プログラム記憶部中のオプション処理プログラムを実行するため、オプション処理の指定の変更は業務プロセス定義部中のオプション処理の指定の変更で対処することができる。このため、業務プロセスの変更に伴うオプション処理の指定の変更、つまり一連の作業工程間で受け渡される情報に関する情報処理の変更を簡便に実施することが可能となる。特に、作業工程間で受け渡される情報を一意に識別する情報、その情報に関連して実施するオプション処理を一意に識別するオプション処理名、そのオプション処理を実施する条件となる当該情報にかかる操作種別及びそのオプション処理を実施するタイミングの指定をオプション処理マスタで定義する構成にあっては、どのような情報が、どのように操作されたときに、どのようなタイミングでオプション処理を実行するのかをきめ細かく制御でき、且つ、その変更もオプション処理マスタの更新で行える。また、オプション処理プログラムは独立したプログラムとしてオプション処理プログラム記憶部に記憶されており、オプション処理の内容の変更もオプション処理プログラム記憶部の変更で対処することができる。
【００２７】
第２の業務処理管理システム及び方法にあっては、業務プロセスを構成する一連の作業工程間で受け渡される情報を、当該業務プロセスを構成する一連の作業工程間の情報の流れの順だけでなく、関連する他の業務プロセスに関連付けて共有データベースに記憶できるため、業務プロセスの単位を細分化し、階層的に管理することができる。たとえば或る製品Ａを部品ａ１、ａ２から製造する生産システムを考えた場合、製品Ａに関連する仕事の一連の作業工程、部品ａ１に関連する仕事の一連の作業工程、部品ａ２に関連する仕事の一連の作業工程をそれぞれ業務プロセスとして定義すれば、各業務プロセスの一連の作業工程間の情報の流れ順に仕事に必要な情報を管理しつつ、部品ａ１および部品ａ２にかかる情報と製品Ａにかかる情報とを関連付け、全体として或るまとまった業務処理にかかる情報を管理することができる。こうすると、製品Ａ、部品ａ１、ａ２の何れかの一連の作業工程が変更された場合には、変更された一連の作業工程を再定義するだけで済み、業務プロセスの変更に伴う定義情報の変更箇所を局所化でき、迅速な対応が可能となる。また、関連付けを用途キーによって行うため、製品Ａの情報に部品ａ１、ａ２の情報のコピーを付随させ、逆に部品ａ１、ａ２の情報に製品Ａの情報のコピーを付随させる場合のような重複した情報の記憶が不要となる。
【００２８】
また第１の業務処理管理システム及び方法にあっては、業務プロセスを構成する一連の作業工程間の情報の流れを、一連の作業工程からなる単位業務における情報の流れを定義した業務手順マスタと、単位業務間の情報の流れを定義した業務フローマスタとによって定義するため、単位業務内における情報の流れの変更は業務手順マスタの定義を変更することで対処でき、単位業務間の情報の流れの変更は業務フローマスタの定義を変更することで対処できる。従って、業務プロセスの変更に伴う定義情報の変更箇所をより局所化でき、迅速な対応が可能となる。
【００２９】
例えば、作業工程ｐ１→作業工程ｋ１→作業工程ｋ２→作業工程ｋ３→作業工程ｐ２からなる業務プロセスＰ、作業工程ｑ１→作業工程ｋ１→作業工程ｋ２→作業工程ｋ３→作業工程ｑ２からなる業務プロセスＱがあるとき、「作業工程ｐ１→作業工程ｐ２」、「作業工程ｑ１→作業工程ｑ２」、「作業工程ｋ１→作業工程ｋ２→作業工程ｋ３」をそれぞれ１つの業務単位Ｘ、Ｙ、Ｚとして、各業務単位における情報の流れを業務手順マスタに定義する。また、業務単位Ｘと業務単位Ｚとの情報の流れ「作業工程ｐ１→作業工程ｋ１、作業工程ｋ３→作業工程ｐ２」、業務単位Ｙと業務単位Ｚとの情報の流れ「作業工程ｑ１→作業工程ｋ１、作業工程ｋ３→作業工程ｑ２」を業務フローマスタに定義する。こうすると、業務改善などにより業務単位Ｚの作業工程が「作業工程ｋ１→作業工程ｋ３」に変更されても、業務単位Ｚの業務手順定義だけを変更するだけで対処できる。また、業務プロセスＰ、Ｑにおいて作業工程ｐ２、ｑ２に続いて別の作業工程を行うように業務プロセスが変更された場合、別の作業工程を例えば「作業工程ｒ１→作業工程ｒ２」とすると、これを１つの業務単位Ｗとして業務手順マスタに定義し、業務単位Ｐと業務単位Ｗとの情報の流れ「作業工程ｐ２→作業工程ｒ１」、業務単位Ｑと業務単位Ｗとの情報の流れ「作業工程ｑ２→作業工程ｒ１」を業務手順に定義することで、新規な作業工程の追加にも容易に対処することができる。更に、業務プロセスＰ、Ｑの何れか一方または双方で業務単位Ｚを必要としなくなった場合、業務フローマスタから業務単位Ｘ、Ｙと業務単位Ｚとの情報の流れの定義を削除することで容易に対処することができる。
【００３０】
第３の業務処理管理システム及び方法にあっては、共有データベースが、作業工程間で受け渡されるデータの情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有しているため、共通情報要素以外の個別情報要素が新たに発生した場合、プロパティテーブルを追加するだけで対処可能となり、本体部分である共通テーブルに新規なデータ項目を追加するような大掛かりな作業が不要となる。
【００３１】
第４の業務処理管理システム及び方法にあっては、業務プロセスを構成する複数の作業工程間で受け渡される情報が、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、デマンド情報はデマンドテーブルを通じて受け渡され、サプライ情報はサプライテーブルを通じて受け渡される。このように、仕事の依頼に関するデータ（デマンド情報）のみならず、その仕事の実績報告（サプライ情報）をも保存して管理することで、現状把握や業務分析がより詳細に行える。
【００３２】
第５の業務処理管理システム及び方法にあっては、前記デマンドテーブル及び前記サプライテーブルのデータ項目が、誰が（Ｗｈｏ）に相当する情報要素を格納するデータ項目、誰に（Ｗｈｏｍ）に相当する情報要素を格納するデータ項目、何を（Ｗｈａｔ）に相当する情報要素を格納するデータ項目、どうする（Ｈｏｗ−Ｄｏ）に相当する情報要素を格納するデータ項目として汎用的なデータ項目とされ、また第７の業務処理管理システムにあっても、いつ（Ｗｈｅｎ）に相当する情報要素を格納するデータ項目、どこに（Ｗｈｅｒｅ）に相当する情報要素を格納するデータ項目、いくつ（Ｈｏｗ−Ｍａｎｙ）に相当する情報要素を格納するデータ項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相当する情報要素を格納するデータ項目、いくらで（Ｈｏｗ−Ｍｕｃｈ）に相当する情報要素を格納するデータ項目として汎用的なデータ項目とされているため、事前に想定した特定の業務用だけでなく、任意の業務に汎用的に使用することが可能となる。
【００３３】
【発明の実施の形態】
次に本発明の実施の形態の例について図面を参照して詳細に説明する。
【００３４】
図１は本発明の一実施の形態にかかる業務処理管理システムの構成図である。この例の業務処理管理システムは、サーバ１と、このサーバ１にネットワーク２を通じて接続された複数のクライアント端末３とを含んで構成され、サーバ１には、共有データベース４、業務プロセス定義部５、オプション処理プログラム記憶部８及び各種の業務ファイル９が接続され、各クライアント端末３には表示装置６及び入力装置７が接続されている。また、サーバ１は、ファイル管理部１１、処理部１２及び通信制御部１３を備え、各クライアント端末３は、通信制御部３１及びユーザ入出力部３２を備えている。
【００３５】
業務プロセス定義部５は、業務プロセスを構成する一連の作業工程間で受け渡される情報の種類の定義、その情報の流れの定義、及び作業工程間で受け渡される情報に関連して実施すべき情報処理であるオプション処理の指定の定義を記憶する装置であり、デマンドサプライマスタ５１、業務手順マスタ５２、業務フローマスタ５３及びオプション処理マスタ５４を有する。本実施の形態では、業務プロセスを構成する複数の作業工程間で受け渡される情報には、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報との２通りがあり、デマンド情報及びサプライ情報にはそれぞれ複数の種類がある。デマンド情報の種類をデマンド種、サプライ情報の種類をサプライ種と呼ぶ。同じ種類のデマンド情報とサプライ情報とはペアになる。デマンドサプライマスタ５１は、業務プロセスで必要な全てのデマンド情報及びサプライ情報の種類（デマンド種、サプライ種）を定義するマスタファイルである。このデマンドサプライマスタ５１に定義されない種類のデマンド情報及びサプライ情報の登録はサーバ１によって拒否される。
【００３６】
業務手順マスタ５２及び業務フローマスタ５３は、業務プロセスを構成する一連の作業工程間で受け渡される情報の流れを定義するマスタファイルである。このうち、業務手順マスタ５２は、一連の作業工程からなる単位業務における情報の流れを定義し、業務フローマスタ５３は、単位業務間の情報の流れを定義する。単位業務は、１つの業務部門内における一連の作業工程に限定されず、複数の業務部門にまたがる一連の作業工程とすることができる。
【００３７】
オプション処理マスタ５４は、デマンド情報及びサプライ情報の操作時に同時に実行されるオプション処理の指定を定義するマスタファイルである。ここで、操作とは、登録、更新、削除の何れか１つ、または複数、または全てを意味する。このオプション処理マスタ５４では、どのようなデマンド種、サプライ種が、どう操作されたときに、どのタイミングで、どのオプション処理を実行するかが定義されており、オプション処理を実行するプログラム自体はオプション処理プログラム記憶部８に記憶されている。どのタイミングとは、操作前のタイミング、操作後のタイミングの何れかを意味する。各種の業務ファイル９は、オプション処理の対象となるデータを記憶するファイルであり、その種類と数は本実施の形態にかかる業務処理管理システムの適用分野およびオプション処理の内容によって決定される。
【００３８】
共有データベース４は、作業工程間で受け渡されるデータを記憶するデータベースである。或る業務を行う担当者がクライアント端末３からサーバ１を通じて業務上のデータを共有データベース４に登録し、別の業務を行う担当者がクライアント端末３からサーバ１を通じて共有データベース４に登録されたデータを参照することで、作業工程間でのデータの受け渡しが行われる。本実施の形態では、共有データベース４は、作業工程間で受け渡されるデータの情報要素のうち、全ての作業工程で共通な共通情報要素を記憶する共通テーブル４１と、それ以外の個別情報要素を記憶する１以上のプロパティテーブル４２とを有している。また、共通テーブル４１はデマンドテーブル４３及びサプライテーブル４４に分けられている。デマンドテーブル４３には、デマンド情報を構成する情報要素のうちの共通情報要素が格納され、サプライテーブル４４には、サプライ情報を構成する情報要素のうちの共通情報要素が格納される。
【００３９】
デマンドテーブル４３及びサプライテーブル４４は、データ項目として、少なくとも、誰が（Ｗｈｏ）に相当する情報要素を格納するデータ項目と、誰に（Ｗｈｏｍ）に相当する情報要素を格納するデータ項目と、何を（Ｗｈａｔ）に相当する情報要素を格納するデータ項目と、どうする（Ｈｏｗ−Ｄｏ）に相当する情報要素を格納するデータ項目とを備える。これは、一般に仕事を依頼する場合、最低限、誰が、誰に、何を、どうするの４要素を伝達すれば良く、依頼された仕事の実績を報告するには、誰が、誰に、何を、どうしたの４要素を伝達すれば良いことに基づく。但し、依頼や報告をより詳細に行うために、デマンドテーブル４３及びサプライテーブル４４は、更に、いつ（Ｗｈｅｎ）に相当する情報要素を格納するデータ項目、どこに（Ｗｈｅｒｅ）に相当する情報要素を格納するデータ項目、いくつ（Ｈｏｗ−Ｍａｎｙ）に相当する情報要素を格納するデータ項目、いつまでに（Ｈｏｗ−Ｌｏｎｇ）に相当する情報要素を格納するデータ項目、いくらで（Ｈｏｗ−Ｍｕｃｈ）に相当する情報要素を格納するデータ項目のうち、少なくとも１つのデータ項目を備えるようにしても良い。また、デマンドテーブル４３とサプライテーブル４４とが同じデータ項目を持っていても良いし、異なるデータ項目を持っていても良い。
【００４０】
また、デマンドテーブル４３及びサプライテーブル４４は、格納するデマンド情報及びサプライ情報を一連の作業工程間の情報の流れの順に関連付けて記憶するためのキーの項目を有している。このためのキーには、自データを一意に識別する自キーと、一連の作業工程の情報の流れにおける自データの直前のデータを識別するための親キーとの２種類がある。或るデータに付された自キーと同じ内容の親キーを持つデータを探索することで、一連の作業工程の情報の流れ方向にデマンド情報、サプライ情報を辿ることができ、反対に、或るデータに付された親キーと同じ内容の自キーを持つデータを探索することで、一連の作業工程の情報の流れと逆方向にデマンド情報、サプライ情報を辿ることができる。また、プロパティテーブル４２に格納される個別情報要素は、その個別情報要素がどのデマンド情報、サプライ情報の属性（プロパティ）であるか、つまり、どの共通情報要素と関連しているかを示すキーの項目を有している。キーの値としては、関連する共通情報要素に付加された自キーの値が使われる。
【００４１】
また、デマンドテーブル４３は、更に、或る業務プロセスにかかるデマンド情報を他の業務プロセスに関連付けるための用途キーを有している。用途キーには、関連する他の業務プロセスのデマンド情報に設定された自キーの値が設定される。或る業務プロセスＰのデマンド情報に付された自キーと同じ内容の用途キーを持つデマンド情報を探索することで、業務プロセスＰの下位階層の業務プロセスＱを知ることができ、反対に、業務プロセスＱのデマンド情報に付された用途キーと同じ内容の自キーを持つデマンド情報を探索することで、業務プロセスＱの上位階層の業務プロセスＰを知ることができる。
【００４２】
以上の共有データベース４、業務プロセス定義部５、オプション処理プログラム記憶部８及び各種の業務ファイル９は、サーバ１に接続される記憶装置上に格納される。これらの共有データベース４や各マスタ等へのアクセスの管理は、サーバ１のファイル管理部１１によって行われる。なお、共有データベース４、業務プロセス定義部５、オプション処理プログラム記憶部８および各種の業務ファイル９並びにファイル管理部１１をネットワークを介してサーバ１に接続される別の１以上のサーバによって実現しても良い。
【００４３】
クライアント端末３の表示装置６は、共有データベース４に入力すべきデータや共有データベース４から出力したデータ等を表示するＣＲＴディスプレイ、ＬＣＤ等で構成される。入力装置７は、作業工程間で受け渡すべきデータや各種のコマンド等を入力する装置であり、キーボードやマウス等で構成される。ユーザ入出力部３２は、グラフィカルユーザインタフェースを実現する処理部であり、共有データベース４から入力したデータを予め画面設計された表示画面の様式に合わせて表示し、また表示画面上で作成されたデータを共有データベース４の格納形式に合わせてサーバ１へ送信する。通信制御部３１は、ネットワーク２を介してサーバ１との間で行われるデータ等の送受信を制御する。
【００４４】
サーバ１の処理部１２は、クライアント端末３からの要求に従って共有データベース４に対するデータの入出力を制御すると共にオプション処理の実行を制御する制御部である。サーバ１の通信制御部１３は、ネットワーク２を介してクライアント端末３との間に行われるデータ等の送受信を制御する部分である。
【００４５】
処理部１２は、データの出力に際しては、クライアント端末３から要求されたデータを共有データベース４から取り出し、ネットワーク２経由で要求元のクライアント端末３へ送信する。他方、データの入力に際しては、クライアント端末３から要求されたデータをネットワーク２経由で受信し、共有データベース４に登録する。この際、業務プロセス定義部５に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序でデータが入力されるように制御することで、作業工程間のデータの受け渡しが、事前に定義された順番通りに行われることを保証する。また、クライアント端末３から入力を要求されたデータの情報要素のうち共通情報要素は共通テーブル４１に登録する。共通テーブル４１はデマンドテーブル４３とサプライテーブル４４とに分かれているため、デマンド作業工程から出された共通情報要素はデマンドテーブル４３に、サプライ作業工程から出された共通情報要素はサプライテーブル４４に、それぞれ登録される。クライアント端末３から入力を要求されたデータの情報要素のうち個別情報要素は、該当するプロパティテーブル４２に登録する。処理部１２はまた、クライアント端末３からの要求に従って共有データベース４に登録されたデータの更新、削除も実施する。そして、処理部１２は、共有データベース４へのデータの登録、更新、削除時にオプション処理マスタ５４を参照してオプション処理の有無を判定し、オプション処理が必要であれば、オプション処理プログラム記憶部８中の該当するオプション処理プログラムを実行する。
【００４６】
サーバ１及びクライアント端末３は、パーソナルコンピュータ、ワークステーション等の情報処理装置によって構成される。サーバ１上のファイル管理部１１、処理部１２及び通信制御部１３、クライアント端末３上の通信制御部３１及びユーザ入出力部３２は、サーバ１及びクライアント端末３を構成する情報処理装置のハードウェアによって、またその記憶装置に格納されるプログラムを実行することによって実現される。
【００４７】
図２は本実施の形態にかかる業務処理管理システムのより詳しい説明を行うために便宜上想定した業務プロセスのモデルを示す。Ａ、Ｂ、Ｃ、Ｄ、Ｅの５つの作業工程があり、これら複数の作業工程間でＤ１〜Ｄ３、Ｓ１〜Ｓ３のデータが受け渡される。このうち、Ｄ１〜Ｄ３はそれぞれ異なる種類のデマンド情報を示し、Ｓ１〜Ｓ３はそれぞれ異なる種類のサプライ情報を示す。また、Ｄ１とＳ１、Ｄ２とＳ２、Ｄ３とＳ３はそれぞれペアとなるデマンド情報及びサプライ情報である。業務プロセスとしては、作業工程Ａから始まる業務プロセスＰと、作業工程Ｂから始まる業務プロセスＱとが存在し、双方の業務プロセスＰ、Ｑは同じ作業工程Ｃ、Ｄ、Ｅを含んでいる。業務プロセスＰでは、作業工程Ａ→作業工程Ｃ→作業工程Ｄ→作業工程Ｃ→作業工程Ｅ→作業工程Ｃ→作業工程Ａの順で業務が行われ、業務プロセスＱでは、作業工程Ｂ→作業工程Ｃ→作業工程Ｄ→作業工程Ｃ→作業工程Ｅ→作業工程Ｃ→作業工程Ｂの順で業務が行われる。一連の作業工程中に同じ作業工程が現れているが、これは１つの作業工程が幾つかの作業工程に分かれていることを想定している。また、一連の作業工程からなる単位業務として、図２に示す単位業務Ｘ、Ｙ、Ｚを想定する。さらに、業務プロセスＰは業務プロセスＱの上位階層のプロセスとする。上位階層のプロセスとは、自プロセスの業務を遂行するに際して下位階層のプロセスの業務を必要とするプロセスを意味する。例えば、部品ａ１で作られる製品Ａがあるとき、製品Ａにかかる業務プロセスは部品ａ１にかかる業務プロセスの上位階層のプロセスであり、部品ａ１にかかる業務プロセスは製品Ａにかかる業務プロセスの下位階層のプロセスである。また、デマンド情報及びサプライ情報の操作時に同時に実行されるオプション処理として、図２にＯＰ００１〜ＯＰ００６で示す６種類のオプション処理を想定する。
【００４８】
図３はデマンドサプライマスタ５１の論理的な構成例を示す。図３に示すように、デマンドサプライマスタ５１には、デマンド種５１−１とサプライ種５１−２とがペアで定義される。図２のモデルの場合、Ｄ１とＳ１、Ｄ２とＳ２、Ｄ３とＳ３がそれぞれのレコードＲ１１〜Ｒ１３に登録される。
【００４９】
図４は業務手順マスタ５２の論理的な構成例を示す。図４に示すように、業務手順マスタ５２には、各単位業務における作業工程間で受け渡す個々のデマンド情報及びサプライ情報毎に、そのデマンド／サプライ種５２−３と、手順区分５２−１、親デマンド／サプライ種５２−２、順序５２−４、種別５２−５とがそれぞれのレコードＲ２１〜Ｒ２８に定義される。手順区分５２−１は単位業務を一意に識別する識別子であり、親デマンド／サプライ種５２−２は当該単位業務内における当該デマンド／サプライ種５２−３の直前に受け渡されるデマンド／サプライ種を示し、順序５２−４は当該単位業務内における当該デマンド／サプライ種の順番を示し、種別５２−５は当該デマンド／サプライ種がデマンド種か、サプライ種かの種別を示す。図２のモデルの場合、単位業務Ｘ及び単位業務Ｙにはデマンド種Ｄ１、サプライ種Ｓ１の２つがあり、単位業務Ｚにはデマンド種Ｄ２、Ｄ３、サプライ種Ｓ２、Ｓ３の４つがあるため、それらについて図４に示されるように定義されている。
【００５０】
例えばレコードＲ２２は、単位業務Ｘにおいて、サプライ種Ｓ１は、デマンド種Ｄ１の次に引き渡される情報であり、その順番は２番目であることを示す。また、業務単位Ｘ及び業務単位Ｙのデマンド種Ｄ１について親デマンド／サプライ種５２−２に「−」が設定されているのは、このデマンド種Ｄ１は最初に受け渡されるデマンド種であることを示す。なお、図４に示すように、単位業務Ｘ、Ｙ、Ｚにおける情報の流れ順に定義レコードＲ２１〜Ｒ２８を並べる場合、各単位業務における情報の流れはレコードの順序で一意に決定されるので、順序５２−４を省略することもできる。また、種別５２−５を設けているが、デマンド／サプライ種５２−３に設定されるデマンド種及びサプライ種のコード自体でデマンド種か、サプライ種かを判別できる場合には省略しても良い。
【００５１】
図５は業務フローマスタ５３の構成例を示す。図５に示すように、業務フローマスタ５３には、単位業務間をまたがる情報の流れ毎に、飛び戻り区分５３−１、親手順区分５３−２、親デマンド／サプライ種５３−３、手順区分５３−４、デマンド／サプライ種５３−５がレコードＲ３１〜Ｒ３４によって定義される。飛び戻り区分５３−１には、或る単位業務から別の単位業務へ飛ぶ流れにはその旨を示すコード「Ｇ」が設定され、飛んだ先の単位業務から元の単位業務へ戻る流れにはその旨を示すコード「Ｒ」が設定される。親手順区分５３−２及び親デマンド／サプライ種５３−３には、情報の流れの上流側の単位業務及びデマンド／サプライ種が設定され、手順区分５３−４及びデマンド／サプライ種５３−５には、情報の流れの下流側の単位業務及びデマンド／サプライ種が設定される。例えば、レコードＲ３１は、単位業務Ｘのデマンド種Ｄ１の次は単位業務Ｚのデマンド種Ｄ２に情報の流れが飛ぶことを示し、レコードＲ３２は、単位業務Ｚのサプライ種Ｓ３の次は単位業務Ｘのサプライ種Ｓ１に情報の流れが戻ることを示す。
【００５２】
単位業務間の情報の流れを定義した業務フローマスタ５３は、単位業務における情報の流れを定義した業務手順マスタ５２より優先される。例えば、図４のレコードＲ２２は、単位業務Ｘにおけるサプライ種Ｓ１は、単位業務Ｘにおけるデマンド種Ｄ１を親デマンド種としているが、図５のレコードＲ３１は、単位業務Ｚのデマンド種Ｄ１から単位業務Ｚのデマンド種Ｄ２に情報の流れが飛ぶことを定義してあるため、情報の流れは、単位業務Ｘのデマンド種Ｄ１→単位業務Ｚのデマンド種Ｄ２となる。結局、図４の業務手順マスタ５２及び図５の業務フローマスタ５３によって、以下のような２つの情報の流れが定義されていることになる。
（ｐ）業務単位Ｘのデマンド種Ｄ１→業務単位Ｚのデマンド種Ｄ２→業務単位Ｚのサプライ種Ｓ２→業務単位Ｚのデマンド種Ｄ３→業務単位Ｚのサプライ種Ｓ３→業務単位Ｘのサプライ種Ｓ１
（ｑ）業務単位Ｙのデマンド種Ｄ１→業務単位Ｚのデマンド種Ｄ２→業務単位Ｚのサプライ種Ｓ２→業務単位Ｚのデマンド種Ｄ３→業務単位Ｚのサプライ種Ｓ３→業務単位Ｙのサプライ種Ｓ１
【００５３】
図６はオプション処理マスタ５４の論理的な構成例を示す。図６に示すように、オプション処理マスタ５４には、作業工程間で受け渡されるデマンド情報やサプライ情報のうちオプション処理が必要となるもの毎に、手順区分５４−１、デマンド／サプライ種５４−２、更新区分５４−３、処理区分５４−４およびオプション処理名５４−５がそれぞれのレコードＲ４１〜Ｒ４８に定義される。オプション処理名５４−５は実行すべきオプション処理プログラムを一意に識別する識別子である。手順区分５４−１およびデマンド／サプライ種５４−２は作業工程間で受け渡される情報を一意に識別する情報であり、当該オプション処理を実行する単位業務およびデマンド／サプライ種を指定するものである。更新区分５４−３は当該オプション処理を当該デマンド／サプライ種の登録、更新、削除の何れの操作時に実行すべきかを指定するもので、Ｉは登録時、Ｕは更新時、Ｄは削除時をそれぞれ示す。処理区分５４−４は、当該オプション処理を操作前に実行すべきか、操作後に実行すべきかを指定するもので、ＡＦは操作後に実行すべきことを、ＢＦは操作前に実行すべきことをそれぞれ示す。図２のモデルの場合、単位業務Ｘ及び単位業務Ｙにはデマンド種Ｄ１、サプライ種Ｓ１についてオプション処理ＯＰ００１、ＯＰ００２があり、単位業務Ｚにはデマンド種Ｄ２、サプライ種Ｓ２についてオプション処理ＯＰ００３、ＯＰ００４〜ＯＰ００６があるため、それらについて図６に示されるように定義されている。
【００５４】
例えばレコードＲ４１は、単位業務Ｘにおけるデマンド種Ｄ１の登録時、その登録後にオプション処理名ＯＰ００１のオプション処理を実行することを定義している。またレコードＲ４７は、単位業務Ｚにおけるサプライ種Ｓ２の削除時、その削除前にオプション処理名ＯＰ０００５のオプション処理を実行することを定義している。なお、デマンド種およびサプライ種の登録時のみなど、特定の操作時にのみオプション処理を実行する場合には更新区分５４−３は省略して良い。また、操作前、操作後の何れか一方でのみオプション処理を実行する場合、処理区分５４−４は省略して良い。
【００５５】
図７はデマンドテーブル４３及びサプライテーブル４４のデータ項目の一例を示す。デマンドテーブル４３は、図７（ａ）に示すように、仕事の要求元を示すデータ項目４３−１、仕事の要求先を示すデータ項目４３−２、要求日時を示すデータ項目４３−３、要求場所を示すデータ項目４３−４、要求する仕事の対象物を示すデータ項目４３−５、対象物の数を示すデータ項目４３−６、仕事の期限を示すデータ項目４３−７、価格を示すデータ項目４３−８、要求する仕事の種類をデマンド種と手順区分で示すデータ項目４３−９、自キー４３−Ａ、親キー４３−Ｂ及び用途キー４３−Ｃを有する。データ項目４３−１〜４３−９は、デマンド情報を構成する情報要素のうち共通情報要素を格納するデータ項目である。自キー４３−Ａは当該デマンド情報を一意に識別するためのキーを格納する項目である。自キー４３−Ａは、デマンド情報を登録する業務担当者が設定する手動設定部分キーと、サーバ１側で設定される自動設定部分キーとから構成される。手動設定部分キーは、データ項目４３−１〜４３−９と物理的に独立に備える以外に、データ項目４３−１〜４３−９の一部を手動設定部分キーとして兼用しても良い。親キー４３−Ｂは一連の作業工程の情報の流れにおける当該デマンド情報の直前の情報（デマンド情報またはサプライ情報）に付された自キーを格納する項目である。用途キー４３−Ｃは当該デマンド情報が属する業務プロセスの上位階層の業務プロセスにおけるデマンド情報に付与された自キーを格納する項目である。
【００５６】
また、サプライテーブル４４は、図７（ｂ）に示すように、実績の報告元を示すデータ項目４４−１、実績の報告先を示すデータ項目４４−２、報告日時を示すデータ項目４４−３、報告場所を示すデータ項目４４−４、報告する対象物を示すデータ項目４４−５、対象物の数を示すデータ項目４４−６、計上日を示すデータ項目４４−７、価格を示すデータ項目４４−８、報告する実績の種類をサプライ種と手順区分で示すデータ項目４４−９、自キー４４−Ａ及び親キー４４−Ｂを、各データ項目として有する。データ項目４４−１〜４４−９は、サプライ情報を構成する情報要素のうち共通情報要素を格納するデータ項目である。自キー４４−Ａは当該サプライ情報を一意に識別するためのキーを格納する項目である。自キー４４−Ａは、サプライ情報を登録する業務担当者が設定する手動設定部分キーと、サーバ１側で設定される自動設定部分キーとから構成される。手動設定部分キーは、データ項目４４−１〜４４−９と物理的に独立に備える以外に、データ項目４４−１〜４４−９の一部を手動設定部分キーとして兼用しても良い。親キー４４−Ｂは一連の作業工程の情報の流れにおける当該サプライ情報の直前の情報（デマンド情報またはサプライ情報）に付された自キーを格納する項目である。
【００５７】
図８はプロパティテーブル４２の論理的な構成例を示す。図８に示すようにプロパティテーブル４２は、キー情報の項目４２−１とプロパティの項目４２−２を有する。プロパティの項目４２−２には、デマンド情報またはサプライ情報の個別情報要素が格納される。キー情報の項目４２−１には、その個別情報要素がどのデマンド情報、サプライ情報に属するかを示す自キーが格納される。自キーは、図７に示した自キー４３−Ａ、４４−Ａに相当する。
【００５８】
図９はデマンド情報及びサプライ情報を共有データベース４へ登録する際の処理例を示し、図９（ａ）はクライアント端末３側の処理を、図９（ｂ）はサーバ１側の処理をそれぞれ示す。
【００５９】
クライアント端末３の業務担当者は、デマンド情報を共有データベース４へ登録する際、共通情報要素だけのデマンド情報で済む場合には、図７（ａ）に示したデータ項目４３−１〜４３−Ｃに対応するデータ項目に必要な値を設定した１つの入力用テーブルを作成し、個別情報要素の登録も行う場合には、個別情報要素の種別に応じた入力用テーブルも併せて作成する（ステップＳ３０１）。これらの入力用テーブルの作成は、ユーザ入出力部３２によって表示装置６の画面に表示されるデマンド入力画面に対し、入力装置７からデータを入力していくことで行われる。その際、親キー４３−Ｂや用途キー４３−Ｃの内容は、後述するように共有データベース４の内容を参照することで知ることができる。サプライ情報を共有データベース４へ登録する際も同様に、共通情報要素だけのサプライ情報で済む場合には、図７（ｂ）に示したデータ項目４４−１〜４４−Ｂに対応するデータ項目に必要な値を設定した１つの入力用テーブルを作成し、個別情報要素の登録も行う場合には、個別情報要素の種別に応じた入力用テーブルも併せて作成する（ステップＳ３０１）。このような入力用テーブルの作成も、ユーザ入出力部３２によって表示装置６の画面に表示されるサプライ入力画面に対し、入力装置７からデータを入力していくことで可能である。
【００６０】
次にクライアント端末３は、ネットワーク２を通じてサーバ１に接続し、デマンド登録時はデマンド登録要求と作成した入力用テーブルとをサーバ１に送信し、サプライ登録時にはサプライ登録要求と作成した入力用テーブルとをサーバ１に送信する（ステップＳ３０２）。この入力用テーブルのクライアント端末３からサーバ１への送信は、クライアント端末３から自発的に行っても良いし、デマンド登録要求、サプライ登録要求を受けたサーバ１がクライアント端末３から入力用テーブルをネットワーク２経由で取り出すことで実現しても良い。その後、クライアント端末３はサーバ１からの応答を待ち、ネットワーク２経由で応答が返されると、それを受信し、応答内容を表示装置６に表示する（ステップＳ３０３）。
【００６１】
他方、サーバ１の処理部１２は、クライアント端末３からデマンド登録要求またはサプライ登録要求および入力用テーブルを受信すると（ステップＳ１０１）、業務プロセス定義部５に定義された一連の作業工程間の情報の流れ通りの順序でデマンド情報またはサプライ情報の登録が行われているか否かを調べる登録可否チェックを実施する（ステップＳ１０２）。このチェックの具体的な処理は後述する。登録不可と判断した場合（ステップＳ１０３でＮＯ）、処理部１２はエラーメッセージを要求元のクライアント端末３へ通知する（ステップＳ１０４）。
【００６２】
他方、登録可能と判断した場合（ステップＳ１０３でＹＥＳ）、処理部１２は、登録前オプション処理の指定が定義されているかどうかを調べる（ステップＳ１０５）。具体的には、登録要求されたデマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定された手順区分とデマンド／サプライ種をキーに図６のオプション処理マスタ５４を検索してオプション処理の指定の有無を調べ、指定があれば、さらに更新区分５４−３がＩ（すなわち登録時）で且つ処理区分５４−４がＢＦ（すなわち登録前）になっているかどうかで、登録前オプション処理の指定が定義されているかどうかを調べる。そして、登録前オプション処理の指定が定義されていた場合には、オプション処理名５４−５に該当するオプション処理プログラムをオプション処理プログラム記憶部８から読み出して実行する（ステップＳ１０６）。登録前オプション処理の指定が定義されていなければ、ステップＳ１０６はスキップする。
【００６３】
次に処理部１２は、登録要求されたデマンド情報またはサプライ情報を共有データベース４へ登録する（ステップＳ１０７）。具体的には、デマンド情報の登録要求の場合、共通情報要素が設定された入力用テーブルの自キー４３−Ａ中の自動設定部分キーをサーバ側で採番して自キー４３−Ａを完成させ、この入力用テーブルの内容を持つ行をデマンドテーブル４３に追加する。また、個別情報要素の種別に応じた入力用テーブルが付随している場合は、その種別に応じたプロパティテーブル４２に当該入力用テーブルの内容を追加する。このとき、図８に示したキー情報４２−１に自キー４３−Ａを設定することにより、個別情報要素を共通情報要素と関連付ける。サプライ情報の登録要求の場合もほぼ同様であり、共通情報要素が設定された入力用テーブルの自キー４４−Ａ中の自動設定部分キーをサーバ側で採番して自キー４４−Ａを完成させて、入力用テーブルの内容を持つ行をサプライテーブル４４に追加し、個別情報要素の種別に応じた入力用テーブルが付随している場合は、その種別に応じたプロパティテーブル４２に当該入力用テーブルの内容を追加する。また、図８に示したキー情報４２−１に自キー４４−Ａを設定し、個別情報要素を共通情報要素と関連付ける。
【００６４】
次に、処理部１２は、登録後オプション処理の指定が定義されているかどうかを調べる（ステップＳ１０８）。具体的には、登録したデマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定された手順区分とデマンド／サプライ種をキーに図６のオプション処理マスタ５４を検索してオプション処理の指定の有無を調べ、指定があれば、さらに更新区分５４−３がＩ（すなわち登録時）で且つ処理区分５４−４がＡＦ（すなわち登録後）になっているかどうかで、登録後オプション処理の指定が定義されているかどうかを調べる。そして、登録後オプション処理の指定が定義されていた場合には、オプション処理名５４−５に該当するオプション処理プログラムをオプション処理プログラム記憶部８から読み出して実行する（ステップＳ１０９）。登録後オプション処理の指定が定義されていなければ、ステップＳ１０９はスキップする。
【００６５】
サーバ１の処理部１２は、以上のようにしてデマンド情報またはサプライ情報の共有データベース４への登録処理を終えると、その旨を要求元のクライアント端末３へ通知する（ステップＳ１１０）。
【００６６】
サーバ１の処理部１２が行う登録可否チェック（Ｓ１０２）の詳細な処理の一例を図１０に示す。先ず処理部１２は、登録要求されたデマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定されたデマンド種またはサプライ種が、デマンドサプライマスタ５１に定義されているか否かを調べ（ステップＳ１１１）、定義されていなければ登録不可と判断する。同時に、このステップＳ１１１において、登録要求された情報がデマンド情報であって、用途キー４３−ＣがＮＵＬＬでないとき、その用途キー４３−Ｃに適合する自キーを持つ他のデマンド情報が既に登録されているか否かを調べ、登録されていなければ登録不可と判断する。
【００６７】
登録要求されたデマンド情報またはサプライ情報のデマンド種またはサプライ種がデマンドサプライマスタ５１に定義されており、且つ、登録要求された情報がデマンド情報であって、用途キー４３−ＣがＮＵＬＬでないときにその用途キー４３−Ｃに適合する自キーを持つ他のデマンド情報が既に登録されている場合、データ項目４３−Ｂまたは４４−Ｂに親キーが設定されているか否かを調べ（ステップＳ１１２）、親キーの設定の有無により処理を切りわける。
【００６８】
親キーが設定されていない場合、デマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定された手順区分及びデマンド種またはサプライ種が、業務プロセスの最初に受け渡される情報として定義されているか否かを業務手順マスタ５２でチェックする（ステップＳ１１３）。このチェックにパスしなければ（ステップＳ１１４でＮＯ）、登録不可と判断する。なお、サプライ情報は業務プロセスの最初に受け渡される情報になり得ないので、親キーの設定がないサプライ情報の登録要求は直ちに登録不可と判断して良い。ステップＳ１１３のチェックにパスした場合、重複登録が行われているか否かをチェックし（ステップＳ１１５）、重複登録の場合には登録不可と判断し、そうでない場合には登録可と判断する。ここで、重複登録とは、デマンド情報またはサプライ情報における自キー４３−Ａ、４４−Ａ中の手動設定部分キーと同じ手動設定部分キーを自キーに持つデマンド情報またはサプライ情報が、デマンドテーブル４３またはサプライテーブル４４に既に登録されている状態を意味する。
【００６９】
他方、親キーが設定されている場合、その親キーと同じ内容を自キー４３−Ａ、４４−Ａに持つデマンド情報またはサプライ情報（親デマンドまたは親サプライ）をデマンドテーブル４３またはサプライテーブル４４から探索し（ステップＳ１１６）、そのような親デマンドまたは親サプライが存在しなければ（ステップＳ１１７でＮＯ）、登録不可と判断する。親デマンドまたは親サプライが存在していた場合（ステップＳ１１７でＹＥＳ）、この存在していた親デマンドまたは親サプライの次に受け渡される情報が今回登録要求されたデマンド情報またはサプライ情報であるか否かを、業務手順マスタ５２及び業務フローマスタ５３を参照してチェックする（ステップＳ１１８）。このチェックにパスしなければ（ステップＳ１１９でＮＯ）、登録不可と判断する。チェックにパスした場合（ステップＳ１１９でＹＥＳ）、ステップＳ１１５に進んで重複登録が行われているか否かをチェックし、重複登録の場合には登録不可と判断し、そうでない場合には登録可と判断する。
【００７０】
図１１に、デマンド情報及びサプライ情報が一連の作業工程間の情報の流れの順に関連付けて記憶されている様子を示す。ここでは、７個のデマンド情報（１）〜（７）と３個のサプライ情報（１）〜（３）が存在する。このうち、デマンド情報（１）、（２）、（５）及びサプライ情報（１）〜（３）は、業務プロセスＰの或る仕事Ｐ００１に関する一連の情報を示し、デマンド情報（３）、（７）は業務プロセスＰの別の仕事Ｐ００２に関する一連の情報を示し、デマンド情報（４）、（６）は業務プロセスＰに関連する別の業務プロセスＱの或る仕事Ｑ００１に関する一連の情報を示す。
【００７１】
業務プロセスＰの或る仕事Ｐ００１に関する最初の情報であるデマンド情報（１）は、データ項目４３−９に手順区分Ｘとデマンド種Ｄ１が設定され、自キー４３−Ａに「Ｐ００１−０１」が設定され、親キー４３−Ｂおよび用途キー４３−ＣはＮＵＬＬになっている。自キー中の「Ｐ００１」は、業務プロセスＰの仕事Ｐ００１を同じ業務プロセスＰや他の業務プロセスＱの仕事と区別するために業務担当者が付与した手動設定部分キーであり、自キー中の「０１」は処理部１２が付与した自動設定部分キーである。情報の流れの順でデマンド情報（１）の次の情報であるデマンド情報（２）は、データ項目４３−９に手順区分Ｚとデマンド種Ｄ２が設定され、自キー４３−Ａに「Ｐ００１−０２」が設定され、親キー４３−Ｂにデマンド情報（１）の自キーの値「Ｐ００１−０１」が設定され、用途キー４３−ＣはＮＵＬＬである。情報の流れの順でデマンド情報（２）の次の情報であるサプライ情報（１）は、データ項目４４−９に手順区分Ｚとサプライ種Ｓ２が設定され、自キー４４−Ａに「Ｐ００１−０２−１」が設定され、親キー４４−Ｂにデマンド情報（２）の自キーの値「Ｐ００１−０２」が設定されている。自キー４４−Ａに設定された自キー中の「Ｐ００１−０２」は、当該サプライ情報がデマンド情報（２）に対するサプライであることを示すために業務担当者が付与した手動設定部分キーであり、自キー中の最後尾の「１」は処理部１２が付与した自動設定部分キーである。以下同様にして、業務プロセスＰの仕事Ｐ００１に関するデマンド情報（５）、サプライ情報（２）、サプライ情報（３）が順次に関係付けられている。
【００７２】
業務プロセスＰの仕事Ｐ００２に関する最初の情報であるデマンド情報（３）は、データ項目４３−９に手順区分Ｘとデマンド種Ｄ１が設定され、自キー４３−Ａに「Ｐ００２−０１」が設定され、親キー４３−Ｂおよび用途キー４３−ＣはＮＵＬＬになっている。自キー中の「Ｐ００２」は、業務プロセスＰの仕事Ｐ００２を同じ業務プロセスＰや他の業務プロセスＱの仕事と区別するために業務担当者が付与した手動設定部分キーであり、自キー中の「０１」は処理部１２が付与した自動設定部分キーである。情報の流れの順でデマンド情報（３）の次の情報であるデマンド情報（７）は、データ項目４３−９に手順区分Ｚとデマンド種Ｄ２が設定され、自キー４３−Ａに「Ｐ００２−０２」が設定され、親キー４３−Ｂにデマンド情報（３）の自キーの値「Ｐ００２−０１」が設定され、用途キー４３−ＣはＮＵＬＬである。業務プロセスＰの仕事Ｐ００２に関する情報は、現時点ではここまでが登録されている。
【００７３】
業務プロセスＱの仕事Ｑ００１に関する最初の情報であるデマンド情報（４）は、データ項目４３−９に手順区分Ｙとデマンド種Ｄ１が設定され、自キー４３−Ａに「Ｑ００１−０１」が設定され、親キー４３−ＢにＮＵＬＬが設定され、用途キー４３−Ｃに業務プロセスＰの仕事Ｐ０００１に関する最初のデマンド情報（１）の自キー４３−Ａの値が設定されている。自キー中の「Ｑ００１」は、業務プロセスＱの仕事Ｑ００１を同じ業務プロセスＱや他の業務プロセスＰの仕事と区別するために業務担当者が付与した手動設定部分キーであり、自キー中の「０１」は処理部１２が付与した自動設定部分キーである。情報の流れの順でデマンド情報（４）の次の情報であるデマンド情報（６）は、データ項目４３−９に手順区分Ｚとデマンド種Ｄ２が設定され、自キー４３−Ａに「Ｑ００１−０２」が設定され、親キー４３−Ｂにデマンド情報（４）の自キーの値「Ｑ００１−０１」が設定され、用途キー４３−Ｃにデマンド情報（１）の自キー４３−Ａの値が設定されている。このように同じ仕事Ｑ００１に関する全てのデマンド情報の用途キー４３−Ｃの値は同じである。業務プロセスＱの仕事Ｑ００１に関する情報は、更に続くが、図１１では図示を省略してある。
【００７４】
図１０に示した登録可否チェック処理では、デマンド情報またはサプライ情報における自キー４３−Ａ、４４−Ａ中の手動設定部分キーと同じ手動設定部分キーを自キーに持つデマンド情報またはサプライ情報は、重複登録として登録を拒否した。しかし、業務の種類やデマンド種、サプライ種によっては、或る１つの仕事を複数に分割して依頼したり、１つの依頼に対して実績を複数回に分けて報告することが行われている。従って、そのような場合には重複登録を認める必要がある。この場合、図１０のステップＳ１１５は図１２のステップＳ１１５−１〜Ｓ１１５−３のように変形される。即ち、今回登録を要求されたデマンド情報またはサプライ情報における自キー４３−Ａ、４４−Ａ中の手動設定部分キーと同じ手動設定部分キーを自キーに持つデマンド情報またはサプライ情報が、デマンドテーブル４３またはサプライテーブル４４に既に登録されていた場合（ステップＳ１１５−１でＹＥＳ）、重複登録制御マスタをチェックして、今回登録を要求された手順区分及びデマンド種またはサプライ種が重複登録可能として定義されているか否かを調べ（ステップＳ１１５−２）、重複登録可能として定義されている場合に限り（ステップＳ１１５−３でＹＥＳ）、登録可と判断する。ここで、重複登録制御マスタは、重複登録を認める手順区分とデマンド種またはサプライ種の組を定義したマスタであり、図１の業務プロセス定義部５に含められる。
【００７５】
図１３に、上述のような重複登録を認めた場合におけるデマンド情報及びサプライ情報の関連付けの例を示す。デマンド情報（１−１）、（１−２）は、１つのデマンド情報を２つに分けて登録したもので、デマンド情報（１−１）は、データ項目４３−９に手順区分Ｘとデマンド種Ｄ１が設定され、自キー４３−Ａに「Ｐ００１−０１」が設定され、親キー４３−Ｂおよび用途キー４３−ＣはＮＵＬＬになっており、デマンド情報（１−２）は、データ項目４３−９に手順区分Ｘとデマンド種Ｄ１が設定され、自キー４３−Ａに「Ｐ００１−０２」が設定され、親キー４３−Ｂおよび用途キー４３−ＣはＮＵＬＬになっている。つまり、自キー４３−Ａの手動設定部分キーは同じ「Ｐ００１」であり、両者を区別するために処理部１２がそれぞれ異なる自動設定部分キー「０１」、「０２」を付与している。デマンド情報（２−１）は、情報の流れの順でデマンド情報（１−１）の次の情報になるデマンド情報であり、データ項目４３−９に手順区分Ｚとデマンド種Ｄ２が設定され、自キー４３−Ａに「Ｐ００１−０３」が設定され、親キー４３−Ｂにデマンド情報（１−１）の自キーの値「Ｐ００１−０１」が設定され、用途キー４３−ＣはＮＵＬＬである。
【００７６】
サプライ情報（１−１）、（１−２）は、デマンド情報（２−１）に対するサプライ情報を２つに分けて登録したもので、サプライ情報（１−１）は、データ項目４４−９に手順区分Ｚとサプライ種Ｓ２が設定され、自キー４４−Ａに「Ｐ００１−０３−１」が設定され、親キー４４−Ｂにデマンド情報（２−１）の自キーの値「Ｐ００１−０３」が設定されており、サプライ情報（１−２）は、データ項目４４−９に手順区分Ｚとサプライ種Ｓ２が設定され、自キー４４−Ａに「Ｐ００１−０３−２」が設定され、親キー４４−Ｂにデマンド情報（２−１）の自キーの値「Ｐ００１−０３」が設定されている。
【００７７】
デマンド情報（２−２）は、情報の流れの順でデマンド情報（１−２）の次の情報になるデマンド情報であり、データ項目４３−９に手順区分Ｚとデマンド種Ｄ２が設定され、自キー４３−Ａに「Ｐ００１−０４」が設定され、親キー４３−Ｂにデマンド情報（１−２）の自キーの値「Ｐ００１−０２」が設定され、用途キー４３−ＣはＮＵＬＬである。
【００７８】
デマンド情報（４−１）、（４−２）は、デマンド情報（１−１）、（１−２）が属する業務プロセスの下位階層の業務プロセスのデマンド情報を２つに分けて登録したもので、デマンド情報（４−１）は、データ項目４３−９に手順区分Ｙとデマンド種Ｄ１が設定され、自キー４３−Ａに「Ｑ００１−０１」が設定され、親キー４３−ＢにＮＵＬＬが設定され、用途キー４３−Ｃにデマンド情報（１−１）の自キー４３−Ａの値が設定されている。また、デマンド情報（４−２）は、データ項目４３−９に手順区分Ｙとデマンド種Ｄ１が設定され、自キー４３−Ａに「Ｑ００１−０２」が設定され、親キー４３−ＢはＮＵＬＬであり、用途キー４３−Ｃにはデマンド情報（１−２）の自キー４３−Ａの値が設定されている。
【００７９】
共有データベース４に登録されたデマンド情報およびサプライ情報を更新する際の処理の流れは基本的には図９と同じである。但し、ステップＳ３０１では更新後のデマンド情報等を設定した入力用テーブルが作成され、ステップＳ３０２ではサーバ１へ更新要求が出される。また、サーバ側の更新可否チェックＳ１０２では、更新対象となるデマンド情報またはサプライ情報が実際に存在するかがチェックされる。更に、ステップＳ１０５では、更新要求されたデマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定された手順区分とデマンド／サプライ種をキーに図６のオプション処理マスタ５４を検索してオプション処理の指定の有無を調べ、指定があれば、さらに更新区分５４−３がＵ（すなわち更新時）で且つ処理区分５４−４がＢＦ（すなわち登録前）になっているかどうかで、更新前オプション処理の指定が定義されているかどうかを調べる。そして、更新前オプション処理の指定が定義されていた場合には、ステップＳ１０６において、オプション処理名５４−５に該当するオプション処理プログラムをオプション処理プログラム記憶部８から読み出して実行する。ステップＳ１０７では、更新要求されたデマンド情報またはサプライ情報で元のデマンド情報またはサプライ情報を更新する。また、ステップＳ１０８では、更新したデマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定された手順区分とデマンド／サプライ種をキーに図６のオプション処理マスタ５４を検索してオプション処理の指定の有無を調べ、指定があれば、さらに更新区分５４−３がＵ（すなわち更新時）で且つ処理区分５４−４がＡＦ（すなわち登録後）になっているかどうかで、更新後オプション処理の指定が定義されているかどうかを調べる。そして、更新後オプション処理の指定が定義されていた場合には、ステップＳ１０９において、オプション処理名５４−５に該当するオプション処理プログラムをオプション処理プログラム記憶部８から読み出して実行する。
【００８０】
共有データベース４に登録されたデマンド情報およびサプライ情報を削除する際の処理の流れも基本的には図９と同じであるが、入力用テーブルは必要なく、クライアント端末３からサーバ１へ削除するデマンド情報またはサプライ情報を特定する情報（例えば自キーなど）を指定して削除を要求する。サーバ１では、削除対象となるデマンド情報またはサプライ情報が実際に存在するか否かをチェックし、存在していれば削除する。削除前オプション処理の有無判定では、削除要求されたデマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定された手順区分とデマンド／サプライ種をキーに図６のオプション処理マスタ５４を検索してオプション処理の指定の有無を調べ、指定があれば、さらに更新区分５４−３がＤ（すなわち削除時）で且つ処理区分５４−４がＢＦ（すなわち登録前）になっているかどうかで、削除前オプション処理の指定が定義されているかどうかを調べる。そして、削除前オプション処理の指定が定義されていた場合には、オプション処理名５４−５に該当するオプション処理プログラムをオプション処理プログラム記憶部８から読み出して実行する。削除後オプション処理の有無判定では、削除したデマンド情報またはサプライ情報のデータ項目４３−９または４４−９に設定された手順区分とデマンド／サプライ種をキーに図６のオプション処理マスタ５４を検索してオプション処理の指定の有無を調べ、指定があれば、さらに更新区分５４−３がＤ（すなわち削除時）で且つ処理区分５４−４がＡＦ（すなわち削除後）になっているかどうかで、削除後オプション処理の指定が定義されているかどうかを調べる。そして、削除後オプション処理の指定が定義されていた場合には、オプション処理名５４−５に該当するオプション処理プログラムをオプション処理プログラム記憶部８から読み出して実行する。
【００８１】
図１４は共有データベース４に登録されたデマンド情報及びサプライ情報を参照する際の処理例を示し、図１４（ａ）はクライアント端末３側の処理を、図１４（ｂ）はサーバ１側の処理をそれぞれ示す。
【００８２】
クライアント端末３の業務担当者は、共有データベース４に登録されたデマンド情報、サプライ情報を参照する場合、検索キーおよびその他の検索条件を指定してネットワーク２経由でサーバ１へ参照要求を送信する（ステップＳ３１１）。検索キーとしては、手順区分、デマンド種、サプライ種、自キー中の手動設定部分キー、用途キーの値、個別情報要素の種別、それらの組み合わせなど、予め検索キーとして定義された任意のキーを使用することができる。その後、クライアント端末３はサーバ１からの応答を待ち、サーバ１からネットワーク２経由でデマンド情報、サプライ情報が送信されてくると、それを受信し、表示装置６に表示する（ステップＳ３１２）。
【００８３】
他方、サーバ１の処理部１２は、ネットワーク２経由でクライアント端末３から参照要求を受信すると（ステップＳ１２１）、指定された検索キーおよびその他の検索条件で共有データベース４のデマンドテーブル４３、サプライテーブル４４、プロパティテーブル４２を検索し、該当するデマンド情報、サプライ情報を取り出す（ステップＳ１２２）。そして、取り出したデマンド情報、サプライ情報をネットワーク２経由でクライアント端末３へ送信する（ステップＳ１２３）。
【００８４】
例えば、図１１に示したようなデマンド情報およびサプライ情報が登録されている状態で、検索キーとして自キー４３−Ａの手動設定部分キーＰ００１を指定し、関連するデマンド情報およびサプライ情報の検索を行った場合、デマンド情報（１）、（２）、サプライ情報（１）、デマンド情報（５）、サプライ情報（２）、（３）が検索され、クライアント端末３に表示される。これにより、業務プロセスＰの仕事Ｐ００１の進捗状況などを把握することができる。
【００８５】
また、検索キーとしてＰ００１−０１を指定して関連下位階層プロセスの検索を行えば、Ｐ００１−０１を自キー４３−Ａに持つ業務プロセスＰの或る仕事Ｐ００１にかかるデマンド情報（１）と、Ｐ００１−０１を用途キー４３−Ｃに持つ業務プロセスＱの仕事Ｑ００１にかかるデマンド情報（４）、（６）が検索され、例えば図１５（ａ）に示すようにクライアント端末３に表示される。これにより、業務プロセスＰの下位階層の業務プロセスＱの仕事の進捗状況などを把握することができる。図１１では、仕事Ｐ００１の下位には仕事Ｑ００１しか存在しなかったが、複数存在する場合には、図１５（ｂ）に示すように関連する全ての下位階層の業務プロセスの仕事にかかるデマンド情報等が検索されて表示される。また、図１１では、仕事Ｑ００１に関連する下位階層の業務プロセスは存在しなかったが、若し存在する場合には、図１５（ｃ）に示すように更に下位の業務プロセスにかかるデマンド情報等が検索されて表示される。関連する下位階層プロセスの検索とは逆に、関連する上位階層プロセスの検索も同様に可能である。
【００８６】
以上の説明では、用途キー４３−Ｃは、関連する他の仕事にかかるデマンド情報の自キー４３−Ａの値すべてを持つものとした。別の実施の形態として、用途キー４３−Ｃに、自キー４３−Ａの値のうちの手動設定部分キーだけを設定するようにしても良い。
【００８７】
【実施例】
次に本発明の実施の形態の実施例について図面を参照して詳細に説明する。本発明は、複数の作業工程から構成される業務プロセスを遂行する企業等であれば業種や業態にかかわらず広く適用可能である。以下では、一例として生産システムに本発明を適用した実施例を説明する。
【００８８】
先ず、図１６及び図１７にそれぞれ異なる生産システムの例を示す。図１６の生産システムは、計画部門を中心としたプッシュ型の生産方式である。顧客（事業部）６１０から受注を受けた計画部門６２０が、部品構成（ＢＭ）展開を行い、部材手配や生産指示を、資材部門６４０や製造検査部門６３０に対して実施する。図１６において、白抜き矢印はデマンド情報、ハッチングを施した矢印はサプライ情報を表しており、実線矢印は、物流を表している。物と情報（デマンド情報とサプライ情報）が図１６に示すように流れている場合、デマンド情報、サプライ情報において、各矢印の元が「誰が（Ｗｈｏ）」、矢印の先が「誰に（Ｗｈｏｍ）」として表現され、指示対象の製品や部品は「何を（Ｗｈａｔ）」、手配や出庫、組配、検査といった指示そのものは「どうする（Ｈｏｗ−Ｄｏ）」として表すことができる。
【００８９】
これに対して図１７は、リーン生産方式を導入したプル型の業務形態を示しており、図１６の生産システムとは全く逆の方式の業務形態を示す。この場合、計画部門（ＳＢＵ）７１０は、検査部門７３０に対してだけ指示を出し、それ以外の工程には、後工程から順次指示が出る。すなわち、計画部門（ＳＢＵ）７１０からの検査指示発行を受け、検査部門７３０から組配部門７４０へ組配指示、組配部門７４０からＳＭＴ（表面実装搭載装置）７５０へ指示、ＳＭＴ７５０から資材部門７２０へ指示がそれぞれ発行され、計画部門（ＳＢＵ）は、図１６のような、資材部門との間で手配等、直接のやりとりは行わない。物と情報（デマンド情報とサプライ情報）が図１７に示すように流れている場合でも、デマンド情報、サプライ情報において、各矢印の元が「誰が（Ｗｈｏ）」、矢印の先が「誰に（Ｗｈｏｍ）」として表現され、指示対象の製品や部品は「何を（Ｗｈａｔ）」、手配や出庫、組配、検査といった指示そのものは「どうする（Ｈｏｗ−Ｄｏ）」として表すことができる。
【００９０】
本発明は図１６及び図１７に示されるような任意の生産システムに対して適用可能であり、また、図１６に示される生産システムを採用していた企業において、図１７に示すような生産システムに変更する際にも適用可能である。
【００９１】
図１８は、本発明の一実施例のシステム構成図である。図１８に示すように、本実施例は、Ｕ−ＲＤＢ（Ｕｎｉｆｉｅｄ Ｒｅｌａｔｉｏｎａｌ Ｄａｔａ Ｂａｓｅ；統合化関係データベース）８０１と呼ばれる共有データベースと、共通コンポーネント群８０２と、業務プロセス及び処理を定義する業務プロセス及び処理定義群８０３とを備えて構成されている。
【００９２】
Ｕ−ＲＤＢ８０１は、デマンド情報及びサプライ情報を格納するデマンド／サプライテーブル８１１、ワークフロー系および在庫系のプロパティを格納する汎用プロパティテーブル８１２、デマンド系およびサプライ系のプロパティを格納する個別プロパティテーブル８１３の３つのデータベース群からなる。図１との関係では、Ｕ−ＲＤＢ８０１は共有データベース４に相当し、デマンド／サプライテーブル８１１はデマンドテーブル４３及びサプライテーブル４４に相当し、汎用プロパティテーブル８１２及び個別プロパティテーブル８１３はプロパティテーブル４２に相当する。
【００９３】
共通コンポーネント群８０２は、データベース（ＤＢ）検索エンジン８２１、構成展開エンジン８２２、在庫シミュレーション８２３、オプション処理群８２４、ＰＯＴ（Ｐｏｒｔａｂｌｅ Ｔｅｒｍｉｎａｌ）／ＢＬＰ（ＢａｒｃｏｄｅＬａｂｅｌ Ｐｒｉｎｔｅｒ）処理群８２５、データベース（ＤＢ）登録更新処理８２６の６種類のコンポーネント群からなる。ＰＯＴは、物流の入出庫業務等で用いられるバーコードリーダ付きの無線端末であり、ＰＯＴ処理群はこの無線端末とデータ及び制御のやり取りを行うためのソフトウェア処理要素群よりなり、ＢＬＰはバーコードラベル印刷用の専用プリンタであり、ＢＬＰ処理群はバーコード印刷用の専用プリンタとデータ及び制御のやり取りを行うソフトウェア処理要素群よりなる。オプション処理群８２４は図１のオプション処理プログラム記憶部８に記憶されたオプション処理プログラムに相当し、具体的にはＳＱＬサーバで動作するプロシージャとして実装される。
【００９４】
また、業務プロセス及び処理定義群８０３は、デマンドサプライマスタ８３１、業務手順マスタ８３２、業務フローマスタ８３３、オプション処理マスタ８３４の各定義マスタからなる。図１との関係では、デマンドサプライマスタ８３１がデマンドサプライマスタ５１に相当し、業務手順マスタ８３２が業務手順マスタ５２に相当し、業務フローマスタ８３３が業務フローマスタ５３に相当し、オプション処理マスタ８３４がオプション処理マスタ５４に相当する。
【００９５】
また、実際に業務として運用するには、外部との連携のため、対人間インタフェース（グラフィカルユーザインタフェース）８０４（各種業務画面等の表示を行う）と、社内外他システムインタフェース８０５が設けられる。図１との関係では、対人間インタフェース８０４は、ネットワーク２経由で接続されたクライアント端末３のユーザ入出力部３２に相当する。ＰＤＭ（Ｐｒｏｄｕｃｔｓ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）は製品情報管理（製品設計情報管理）を意味しており、社内外端末システムインタフェース８０５のＰＤＭは、製品の図面／仕様書などの製品設計情報管理システムとのインタフェースである。また、ＣＡＤ／ＣＡＭ／ＣＡＴは、ＣＡＤ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ；計算機支援設計）システム／ＣＡＭ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｍａｎｕｆａｃｔｕｒｅｉｎｇ；計算機設計製造）システム／ＣＡＴ（ＣｏｍｐｕｔｅｒＡｉｄｅｄ Ｔｅｓｔ；計算機支援試験）システムとのインタフェース、Ｍ／Ｃは工場内での自動化設備（Ｍ／Ｃ；Ｍａｃｈｉｎｅ）とのインタフェースを表している。
【００９６】
対人間インタフェース８０４は、Ｕ−ＲＤＢ８０１の仕様を参考に、個別業務の形態に合わせ、ＭＳ−ＥＸＣＥＬ（商標）、ＭＳ−Ａｃｃｅｓｓ（商標）等、クライアントの使い慣れたツール／言語を使い容易かつ自在に作成できる。そして、そのインタフェース部分は、画面定義やファイル転送内容の編集等であるが、元になるデータベースが共通のＵ−ＲＤＢ８０１のため比較的簡単な情報処理であり、適宜変更追加することが可能であり、クライアント側（エンドユーザ側）でも容易に作成できる。このため、ＢＰＲや業務改善により、業務プロセスの変更が必要な際、このインタフェース構築／変更がネックとなって迅速な対応が損なわれることにはならない。むしろ、エンドユーザが直接、その都度対応できるので、ＩＳ（情報システム）部門に依頼し、バックログとして山積みされ、対応が遅れる弊害から免れることになる。なお、エンドユーザからＵ−ＲＤＢ８０１へのアクセスは、後述するトランスファ（Ｔｒａｎｓｆｅｒ）サーバを介して、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）サーバで行われる。
【００９７】
次に、本実施例の動作について、図面を参照して詳細に説明する。
【００９８】
生産システムの各作業工程間で受け渡される情報は、図１９に示すように、要求／指示９１１Ａ、実行／実績報告９１１Ｂの２つに分類される。要求／指示９１１Ａはデマンド情報に、実行／実績報告９１１Ｂはサプライ情報に相当する。生産システムの場合、デマンド情報には、受注、出荷指示、発注指示、設計指示、入庫指示、検査指示、組配指示、出庫指示、購入指示などの種類（デマンド種）があり、サプライ情報には、これらのデマンド種に対応して、納入、出荷実績、発注実績、設計実績、入庫実績、検査実績、組配実績、出庫実績、購入実績などの種類（デマンド種）がある。本実施例では、これら全てのデマンド種及びサプライ種の基本情報を、幾つかのＷと幾つかのＨとで表現してデマンド／サプライテーブル８１１に登録し、作業工程間で受け渡す。
【００９９】
図１９には、誰が（Ｗｈｏ）、誰に（Ｗｈｏｍ）、いつ（Ｗｈｅｎ）、どこで（Ｗｈｅｒｅ）、何を（Ｗｈａｔ）の５つのＷと、いくつ（Ｈｏｗ−Ｍａｎｙ）、いつまでに（Ｈｏｗ−Ｌｏｎｇ）、いくらで（Ｈｏｗ−Ｍｕｃｈ）、どうしろ（Ｈｏｗ−Ｄｏ）の４つのＨとで表現する場合を示す。また、この５Ｗと４Ｈで表現できない個別情報要素は、属性（補完情報）として汎用プロパティテーブル８１２及び個別プロパティテーブル８１３に登録し、作業工程間で受け渡す。補間情報として、図１９には、受注仕様、図面、管理区分、検査結果、品質情報、予定情報などが示されている。なお、いつ（Ｗｈｅｎ）、どこに（Ｗｈｅｒｅ）の２つのＷと、いくつ（Ｈｏｗ−Ｍａｎｙ）、いつまでに（Ｈｏｗ−Ｌｏｎｇ）、いくらで（Ｈｏｗ−Ｍｕｃｈ）の３つのＨとの、２Ｗと３Ｈは、その何れか１つ又は複数または全部をなくして、個別情報要素として管理することもできる。
【０１００】
そして、本実施例においては、システムに登録できるデマンド種、サプライ種についてデマンドサプライマスタ８３１に定義し、また一連の作業工程間の情報の流れを業務手順マスタ８３２及び業務フローマスタ８３３に定義しておき、対人間インタフェース８０４からデマンド情報またはサプライ情報の登録が要求されたとき、データベース登録更新コンポーネント８２６で登録の可否をチェックし、情報の受け渡しが事前に定義された情報の流れの順序通りに行われるように制御している。
【０１０１】
図２０にデマンドテーブルの内容の一例を模式的に示す。デマンドテーブルのデータ項目として、誰が、誰に、何をの３つのＷと、いくつ、いつまでに、いくらで、どうする（デマンド種）の４つのＨとの汎用的な名称のデータ項目がある。これらのデータ項目は、各デマンド種に応じた具体的なデータ項目名称に対応する。例えば、受注の場合、誰がは顧客に、誰には受注者に、何をは受注オーダ、客先注文番号および品名コードに、いくつは注文数に、いつまでは納期に、いくらは売価に、どうする（デマンド種）は受注に、それぞれ対応する。他のデマンド種についても図２０に示すようなデータ項目がそれぞれ対応する。なお、図２０では、何をのデータ項目中に自キーと親キーとを含めているが、自キーと親キーとをそれぞれ独立した項目として設けても良い。
【０１０２】
図２１は本発明の一実施例による実際の業務遂行の様子を示す模式図であり、或る通信機製造工場の生産システムの一部を表している。以下、計画部門とその関連部門における業務事例に即して説明する。なお、業務プロセスに関するデマンド／サプライ種と、デマンド／サプライ情報の流れは、図１８のデマンドサプライマスタ８３１、業務手順マスタ８３２及び業務フローマスタ８３３に予め定義されている。
【０１０３】
計画部門Ａ１の生産手配担当者は、計画に基づき、製造部門Ａ２への組配指示８１１Ａ４と、必要資材の手配である購入要求８１１Ａ１を、それぞれデマンド情報としてＵ−ＲＤＢ８０１のデマンドテーブル８１１Ａに登録する。その際、誰が（Ｗｈｏ）は「計画部門Ａ１」であり、誰に（Ｗｈｏｍ）はそれぞれ「製造部門Ａ２」と「購買部門Ａ３」になる。各部門は、自部門に出されたデマンド情報をＵ−ＲＤＢ８０１のデマンドテーブル８１１Ａから参照して業務を遂行し、業務を完了すると、各デマンド情報に対応する「実績」を、Ｕ−ＲＤＢ８０１のサプライテーブル８１１Ｂにサプライ情報として登録することで、報告とする。この場合、購入要求デマンド８１１Ａを受けた購買部門Ａ３は、さらに取引先Ａ４に対して、購入発注デマンド８１１Ａ２を発行して注文する。取引先Ａ４が納入すると、納入実績８１１Ｂ２をサプライ情報として計上し、同時に、購入要求８１１Ａ１のサプライ情報を、購入実績８１１Ｂ１として、サプライテーブル８１１Ｂに登録する。最後に、計画部門Ａ１は、この実績を受け、物流部門Ａ５に対して、入庫指示デマンド８１１Ａ３を発行する。このような流れで、仕事に必要な情報が受け渡されて業務が遂行される。
【０１０４】
次に、デマンド情報、サプライ情報の流れを定義する業務手順マスタ８３２及び業務フローマスタ８３３について、図２１に示した業務プロセス事例を業務手順マスタ８３２と業務フローマスタ８３３に定義した状態を模式的に示す図２２を参照して説明する。図２２において、計画部門Ａ１が発行するデマンド（購入要求８１１Ａ１と組配指示８１１Ａ４）の手順は、それぞれ、９００と９０１で表現される。手順９００では、購入要求デマンド９００−１を発行し、そのサプライである購入実績サプライ９００−２が計上されると、入庫指示デマンド９００−３を出し、入庫完了で入庫実績サプライ９００−４を計上するという手順を規定している。この手順９００の定義情報が、業務手順マスタ８３２に登録されている。また、購入要求デマンド９００−１を受けた購入部門Ａ３の購入の手順として、手順９０２が定義されており、この手順９０２が完了すると、手順９００の手順に戻っていく流れとなる。この場合の、手順９００から手順９０２への飛び、手順９０２から手順９００への戻りの関係を定義したものが、業務フローマスタ８３３である。
【０１０５】
図２３は本発明の一実施例によるオプション処理の実行例を示す模式図であり、（ａ）は庫材出庫デマンド登録時のオプション処理例を、（ｂ）は庫材出庫実績サプライ登録時のオプション処理例をそれぞれ示す。
【０１０６】
図２３（ａ）では、庫材出庫デマンド１００１のデマンドテーブル１００２への登録時、オプション処理マスタ８３４で定義された指定に従ってオプション処理として有効在庫計算処理１００３が実行され、ＢＭプロパティ（部品構成表）１００４を参照して、庫材出庫デマンド１００１の内容に基づいて有効在庫マスタ１００５を自動的に更新している。
【０１０７】
図２３（ｂ）では、庫材出庫実績サプライ１０１１のサプライテーブル１０１２への登録時、オプション処理マスタ８３４で定義された指定に従ってオプション処理として在庫数計算処理１０１３が実行され、庫材出庫実績サプライ１０１１の内容に基づいて在庫数マスタ１０１４を自動的に更新している。
【０１０８】
次に、本発明の一実施例で用いられるサーバ環境について、図２４を参照して説明する。各部署に配置された端末Ｈ２から、実際に各種のデマンド情報およびサプライ情報の入力や検索が行われるが、この処理は、端末からの処理の振り分けを行う仲介サーバとして機能するトランスファ（Ｔｒａｎｓｆｅｒ）サーバＨ１に対して、要求種別や検索キーなどを表す処理パラメータＨ２−１とデータＨ２−２を送ることで行われる。トランスファサーバＨ１は、端末Ｈ２から送られた処理パラメータＨ２−１及びデータＨ２−２を受け取り、処理パラメータＨ２−１の要求種別に対応する基幹サーバＨ３、Ｈ４、Ｈ５（ＳＱＬサーバ）や、他のサーバを選択して、処理を実行させる。ここで、基幹サーバＨ３は、デマンド／サプライテーブル８１１を保持管理したりオプション処理を実行するサーバ、基幹サーバＨ４は、生産ＢＭ等を保持管理するサーバ、基幹サーバＨ５は、仕様書、図面、ＣＡＤデータ等のプロパティテーブル８１２、８１３を保持管理するサーバである。
【０１０９】
例えば、トランスファサーバＨ１は、デマンド登録処理やサプライ登録処理が要求された場合には、基幹サーバＨ３を選択し、ＤＢ登録更新コンポーネント８２６（図１８参照）を実行させ、デマンド情報やサプライ情報を、デマンド／サプライテーブル８１１（図１８参照）に登録する。また、受け取った要求が、検索要求の場合、必要な基幹サーバにＤＢ検索エンジン８２１を実行させることで検索を行わせる。例えば、受け取った要求が組配指示情報と組縦図面を検索する場合には、基幹サーバＨ３に、ＤＢ検索エンジン８２１を実行させるとともに、図面／仕様書が格納されている基幹サーバＨ５を選択し、必要な情報を取り出し、端末Ｈ２に渡す処理を行う。
【０１１０】
トランスファサーバＨ１は、他システムとの接続も管理実行する機能を持つ。事例では、表面実装搭載装置（ＳＭＴ）Ｈ７への作業指示、搭載仕様／実績収集、他者システムＨ６への情報転送などを行っている。これらの転送情報も、デマンド／サプライの個別プロパティの一種として、個別プロパティテーブル８１３に登録される。また、トランスファサーバＨ１は、端末Ｈ２の担当者に構成展開エンジン８２２や在庫シミュレーション８２３等の機能を提供する。
【０１１１】
次に、図２５を参照して、汎用プロパティテーブル８１２及び個別プロパティテーブル８１３について説明する。汎用プロパティテーブル８１２は、システムとして標準的に備わるプロパティテーブルであり、ワークフロー系プロパティテーブルと、図２５には図示していないが在庫系プロパティテーブルとに大別される。ワークフロー系プロパティテーブルは、デマンドの受け渡しやデマンドに対する納期回答情報などの支援をするためのテーブルである。具体的には、デマンドを受け付けた側が指定デマンドに対する実行可否判断後に意思表示を行うためのデマンド受け付けプロパティテーブル、デマンド受けた側が日程および数量の回答（予定入力）を行うデマンド予定プロパティテーブル、サプライ入力時にデマンドのキーを取得するための伝票番号情報を管理する伝票番号制御プロパティテーブルなどがある。
【０１１２】
他方、個別プロパティテーブル８１３は、デマンド系プロパティテーブルとサプライ系プロパティテーブルとに分類される。デマンド系プロパティテーブルは、品目仕様、購買条件、トップシート、図面製造仕様、工事仕様ＮＣデータ、試験仕様、出荷仕様などの種類があり、それぞれ、デマンドテーブルの該当するデマンド情報と関連付けられる。サプライ系プロパティテーブルは、検査結果、不具合・品質、入出庫履歴、在庫・有効、工数・労間、試験データなどの種類があり、それぞれ、サプライテーブルの該当するサプライ情報と関連付けられる。
【０１１３】
なお、本発明の一実施例において、社内他システムや社外他社システムにも、同様のデマンド／サプライテーブル及びプロパティテーブルを定義して、当システムと社内他システムや社外他社システムをトランスファサーバＨ１経由で接続し、それらのシステム間でやり取りされるデマンド情報やサプライ情報をＵ−ＲＤＢ８０１に登録するようにしてもよい。これは、企業外システムとの一体化を容易にし、ＳＣＭ（Ｓｕｐｐｌｙ Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔ）の推進に有効であり、また同じ形式のデータベースを共有することで、仮想的な企業連携活動が可能になる。
【０１１４】
図２４の事例では、基幹サーバ群Ｈ３〜Ｈ５と端末Ｈ２の仲介を行うトランスファサーバＨ１を用いているが、トランスファサーバＨ１を使用せず、端末Ｈ２と基幹サーバＨ３〜Ｈ５を直接に接続した環境に本発明を適用することも可能であり、小規模な業務に関しては、その環境で実現する場合もある。
【０１１５】
【発明の効果】
以上説明したように本発明によれば以下のような効果が得られる。
【０１１６】
業務プロセスの変更に対して機敏に変更可能である。その理由は、オプション処理の指定の変更は業務プロセス定義部中のオプション処理の指定の変更で対処することができ、オプション処理の内容はオプション処理プログラム記憶部の変更で対処することができ、一連の作業工程間で受け渡される情報に関する情報処理の変更を簡便に実施することができるからである。特に、作業工程間で受け渡される情報を一意に識別する情報、その情報に関連して実施するオプション処理を一意に識別するオプション処理名、そのオプション処理を実施する条件となる当該情報にかかる操作種別及びそのオプション処理を実施するタイミングの指定をオプション処理マスタで定義する構成にあっては、どのような情報が、どのように操作されたときに、どのようなタイミングでオプション処理を実行するのかをきめ細かく制御でき、且つ、その変更もオプション処理マスタの更新で行える。
【０１１７】
業務プロセスの変更に対してより一層機敏に変更可能である。その理由は、業務プロセスを構成する一連の作業工程間で受け渡される情報を、当該業務プロセスを構成する一連の作業工程間の情報の流れの順だけでなく、他の業務プロセスにかかる情報に関連付けて共有データベースに記憶できるため、業務プロセスの単位を例えば製品Ａに関連するプロセス、製品Ａを構成する個々の部品に関連するプロセスといった単位に分割して定義でき、文献１に記載の従来技術のように互いに関連するプロセスは１つのプロセスとして一括して定義する場合に比べて、業務プロセス変更に伴う定義情報の変更箇所が局所化され、対応が容易になるためである。また、他の業務プロセスとの関連付けを、用途キーによって行うため、互いに相手の情報のコピーを持ち回る場合に比べて、重複した情報の記憶が不要となる。
【０１１８】
業務プロセスの変更に対して更により一層機敏に変更可能である。その理由は、業務プロセスを構成する一連の作業工程間の情報の流れを、一連の作業工程からなる単位業務における情報の流れを定義した業務手順マスタおよび単位業務間の情報の流れを定義した業務フローマスタによって定義しており、業務プロセスの変更に伴う定義情報の変更箇所が局所化されるためである。また、共有データベースが、作業工程間で受け渡されるデータの情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有しているため、共通情報要素以外の個別情報要素が新たに発生した場合、プロパティテーブルを追加するだけで対処できるからである。更に、デマンドテーブル及びサプライテーブルのデータ項目が、５Ｗ１Ｈ等のように汎用的に使用できるデータ項目となっているためである。
【０１１９】
共有データベースにおける無駄なデータ項目を削減することができる。その理由は、文献１に記載の従来技術のように業務プロセスを構成する作業工程に関連する全てのデータ項目の内容を掲示板データベースのテーブルに集約すると、作業工程によっては無駄なデータ項目が存在することになるが、作業工程間で受け渡されるデータの情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルでは、無駄なデータ項目がなくなるからである。
【０１２０】
業務の現在状況の把握や業務分析をより詳しく行うことができる。その理由は、仕事の依頼にかかるデマンド情報だけでなく、依頼された仕事に対する実績報告にかかるサプライ情報を記録して管理するためである。
【図面の簡単な説明】
【図１】本発明の一実施の形態にかかる業務処理管理システムの構成図である。
【図２】本発明の一実施の形態にかかる業務処理管理システムのより詳しい説明を行うために便宜上想定した業務プロセスのモデルを示す図である。
【図３】デマンドサプライマスタの論理的な構成例を示す図である。
【図４】業務手順マスタの論理的な構成例を示す図である。
【図５】業務フローマスタの論理的な構成例を示す図である。
【図６】オプション処理マスタの論理的な構成例を示す図である。
【図７】デマンドテーブル及びサプライテーブルのデータ項目の一例を示す図である。
【図８】プロパティテーブルの論理的な構成例を示す図である。
【図９】デマンド情報及びサプライ情報を共有データベースへ登録する際のクライアント端末側及びサーバ側の処理例を示すフローチャートである。
【図１０】サーバの処理部が行う登録可否チェック（Ｓ１０２）の詳細な処理の一例を示すフローチャートである。
【図１１】デマンド情報及びサプライ情報が一連の作業工程間の情報の流れの順に関連付けて記憶されている様子を示す図である。
【図１２】重複登録を求める場合の登録可否チェックの処理例を示すフローチャートである。
【図１３】重複登録を認めた場合におけるデマンド情報及びサプライ情報の関連付けの例を示す図である。
【図１４】共有データベースに登録されたデマンド情報及びサプライ情報を参照する際のクライアント端末側及びサーバ側の処理例を示すフローチャートである。
【図１５】用途キーによって互いに関連付けられた複数の業務プロセスの仕事にかかるデマンド情報等を検索した際にクライアント端末に表示される内容を模式的に示す図である。
【図１６】生産システムの一例を示す図である。
【図１７】生産システムの他の例を示す図である。
【図１８】本発明の一実施例のシステム構成図である。
【図１９】生産システムの各作業工程間で受け渡される情報の説明図である。
【図２０】本発明の一実施例におけるデマンドテーブルの内容の一例を模式的に示す図である。
【図２１】本発明の一実施例におけるデマンド情報、サプライ情報の流れを定義する業務手順マスタ及び業務フローマスタを説明するための業務プロセス事例を示す図である。
【図２２】図２１に示した業務プロセス事例を業務手順マスタと業務フローマスタに定義した状態を模式的に示す図である。
【図２３】本発明の一実施例によるオプション処理の実行例を示す模式図である。
【図２４】本発明の一実施例で用いられるサーバ環境の構成図である。
【図２５】本発明の一実施例で用いられる汎用プロパティテーブル及び個別プロパティテーブルの説明図である。
【符号の説明】
１…サーバ
２…ネットワーク
３…クライアント端末
４…共有データベース
５…業務プロセス定義部
６…表示装置
７…入力装置
８…オプション処理プログラム記憶部
９…各種の業務ファイル

Claims (22)

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

Images