"複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルを備え、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記ステータスデータは、前記プロセス固有データが更新されたことに応じて更新されることを特徴とするデータベース。前記プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバに備えられ、該プロセスフローデータ管理サーバは、クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段を含む請求項1記載のデータベース。前記プロセスフローの進捗状況の判定条件を示すデータである進捗状況判定条件データが登録された進捗状況判定条件テーブルを備え、前記プロセスフローデータ管理サーバは、前記進捗状況判定条件に基づいて前記ステータスデータが前記進捗状況判定条件を満たしているか判定する進捗状況判定手段と、該進捗状況判定手段により満たしていると判定された進捗状況判定条件に応じた進捗状況を前記クライアント端末に報知する進捗状況報知手段とを含む請求項2記載のデータベース。前記進捗状況判定条件データは、前記プロセスフローが完了したか判定するための完了条件を含む請求項3記載のデータベース。クライアント端末に対して各種データを提供するデータ管理サーバであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、前記プロセスフローの進捗状況に応じて当該プロセスフローデータを更新するプロセスフローデータ更新手段と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段とを含み、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ更新手段は、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新することを特徴とするデータ管理サーバ。クライアント端末に対して各種データを提供するようにデータ管理サーバに動作制御させるためのデータ管理プログラムであって、前記データ管理サーバに、複数の業務プロセスを含むプロセスフローの進捗状況に応じて前記プロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供処理とを実行させ、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ更新処理にて、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新する処理を実行させるためのデータ管理プログラム。しかしながら、従来のERPシステムでは、各業務プロセスにおいて取得されるデータユーザにより入力されるデータと各種データから算出されるデータとを含むを、それぞれ専用のデータテーブルテーブルに登録し、管理している。すなわち、従来のERPシステムにおいては、受注や出荷指示などの入力プロセス毎に、更新するテーブルが異なる。なお、入力プロセスとは、各業務プロセスにおいてERPシステムの管理者などが取得または決定した各種データを、各テーブルに入力する処理を意味する。図10は、従来のERPシステムにおけるテーブル構成の例について説明するための説明図である。例えば、複数の業務プロセスにより構成される業務フロープロセスフローが在庫売上を示すものである場合、入力プロセスは、受注、出荷指示、出庫、検収、および売上の5つとなる。この場合、在庫売上のプロセスフローに関するデータを格納するテーブルは、例えば図10Aから図10Eに示すように、入力プロセス毎にそれぞれ、受注テーブル、出荷指示テーブル、出庫テーブル、検収テーブル、および売上テーブルの5つとなる。すなわち、従来のERPシステムでは、入力プロセス毎に更新するテーブルが異なっていた。そのため、同一のプロセスフローに属する複数の業務プロセス間の対応付けは、各業務プロセスに関するデータプロセスデータに対して識別子図10においては、出荷指示テーブルにおける受注番号と受注明細や、出庫テーブルにおける出荷指示番号と出荷指示明細などを付与することにより行われていた。そのため、従来のERPシステムでは、1つの入力プロセスに対して、入力プロセスの種類に応じたテーブルの特定と、対応する他のプロセスデータの識別子の入力とが必要となっていた。すなわち、例えば図10に示す場合に、受注番号A00001と受注明細番号0010とで特定されるプロセスデータすなわち、受注テーブルにおいて受注番号A00001と受注明細番号0010と同一列に格納された各種データに関連する業務プロセス出荷指示に関するプロセスデータをERPシステムが備えるデータベースに登録する場合、業務プロセス出荷指示に関するプロセスデータとして、プロセスデータを特定するための出荷指示番号と出荷指示明細番号、業務プロセスの種類を示すタイプ、および業務プロセスの内容を示すデータ例えば、受注先、数量、金額、出荷指示日、出荷テキストなどと共に、受注番号A00001と受注明細番号0010とを出荷指示テーブルに登録する必要があった。これは、複数のテーブルに一部同一のデータ例えば、受注先や数量、金額などが登録されてしまうことなど、効率的なデータ処理の観点からみて問題があった。また、従来のERPシステムでは、各種テーブルに格納された各種データを用いてユーザの要求に応じた帳票を作成しようとする場合、プロセスデータの識別子を辿って必要なプロセスデータを検索し、それぞれ別個に取得する必要があるため、プロセスフローが多数の業務プロセスを含む場合、プロセスフローに関する帳票を出力するために要する処理負荷が過大になってしまうという問題があった。本発明は、上述した問題を解消し、ERPシステムにおけるデータの更新や検索に要する処理負荷を軽減させることをできるようにすることを目的とする。本発明のデータベースは、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルを備え、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記ステータスデータは、前記プロセス固有データが更新されたことに応じて更新されることを特徴とする。上記の構成としたことで、ERPシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。前記プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバに備えられ、該プロセスフローデータ管理サーバは、クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段を含む構成とされていてもよい。前記プロセスフローの進捗状況の判定条件を示すデータである進捗状況判定条件データが登録された進捗状況判定条件テーブルを備え、前記プロセスフローデータ管理サーバは、前記進捗状況判定条件に基づいて前記ステータスデータが前記進捗状況判定条件を満たしているか判定する進捗状況判定手段と、該進捗状況判定手段により満たしていると判定された進捗状況判定条件に応じた進捗状況を前記クライアント端末に報知する進捗状況報知手段とを含む構成とされていてもよい。前記進捗状況提供条件データは、前記プロセスフローが完了したか判定するための完了条件を含む構成とされていてもよい。また、本発明のデータ管理サーバは、クライアント端末に対して各種データを提供するデータ管理サーバであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、前記プロセスフローの進捗状況に応じて当該プロセスフローデータを更新するプロセスフローデータ更新手段と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段とを含み、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ更新手段は、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新することを特徴とする。さらに、本発明のデータ管理プログラムは、クライアント端末に対して各種データを提供するようにデータ管理サーバに動作制御させるためのデータ管理プログラムであって、前記データ管理サーバに、複数の業務プロセスを含むプロセスフローの進捗状況に応じて前記プロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供処理とを実行させ、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ更新処理にて、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新する処理を実行させるためのものである。本発明によれば、ERPシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。以下、本発明の一実施の形態の例について図面を参照して説明する。図1は、本発明の一実施の形態に係る統合基幹業務システム500の構成例を示すブロック図である。図1に示すように、統合基幹業務システム500は、基幹業務サーバ200と、データウェアハウスサーバDWHサーバ300と、クライアント10と、クライアント20とを含む。統合基幹業務システム500を構成する各要素は、それぞれ通信ネットワークにより接続される。本例においては、基幹業務サーバ200とDWHサーバ300とは、専用回線51により接続されているものとする。また、クライアント10は、LANLocalAreaNetwork52によりDWHサーバ300と接続されている。また、クライアント20は、インターネット53によりDWHサーバ300と接続されている。基幹業務サーバ200は、例えば統合基幹業務システム500の管理者によって管理されるサーバであり、各種業務に関する帳票情報など、各種業務プロセスにおける情報を示すデータであるプロセスデータを管理するための各種機能を有する。なお、本例における基幹業務サーバ200は、OSOperatingSystemやリレーショナルデータベースリレーショナルDBを備えた一般的な情報処理装置によって構成される。ここで、帳票とは、帳簿や伝票類の総称である。また、帳簿とは、金銭や品物の出納に関する事項が記入されるものであり、伝票とは、帳簿を作成する際の基となるデータであり業務上の取引等の証拠となるものである。なお、基幹業務サーバ200が、例えば、各種伝票の作成に用いる伝票情報のみを示すプロセスデータを扱う構成としてもよい。また、本例における基幹業務サーバ200は、図1に示すように、業務アプリケーションプログラムDB210と、プロセスフローDB220と、一般的な基幹業務サーバとしての機能を実現するために必要な各種データ例えば、業務アプリケーションプログラムDB210に格納される各種プログラムが利用するデータを格納するその他DB230とを備えている。なお、その他DB230については、本発明に特に関係しない部分であるため、詳しい説明は省略する。業務アプリケーションプログラムDB210は、各種業務に用いられるプログラムを記憶する記憶媒体である。業務アプリケーションプログラムDB210に記憶されるプログラムとしては、販売業務管理プログラム、購買業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。プロセスフローDB220は、業務アプリケーションプログラムDB210に記憶された各種プログラムを用いた各種情報処理によって収集整理等された各種のプロセスデータまたは帳票データにより構成されるプロセスフローデータを記憶する記憶媒体である。本例においては、プロセスフローDB220において、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータがプロセスフローテーブルPTに格納される場合について説明する。また、本例においては、基幹業務サーバ200が、プロセスフロー毎に発生するプロセスフローデータを1つのプロセスフローテーブルPTにて一元管理する場合について説明する。なお、基幹業務サーバ200が、プロセスフローデータを、例えば、後述するタイプ毎に、あるいは後述する共通データの内容の一部例えば、受注先などが同じもの毎に、複数のテーブルで管理する構成としてもよい。図2は、プロセスフローDB220におけるプロセスフローデータの格納状態の例を示す説明図である。図2に示すように、本例におけるプロセスフローデータは、主キー部と、参照キー部と、タイプ部と、ステータス部と、共通データ部と、プロセス固有データ部とを含む。なお、プロセスフローデータの各部に対応する項目すなわち、プロセスフローテーブルPTにおける各列項目が、それぞれ、プロセスフローデータを構成するプロセスデータの種類を示す。すなわち、プロセスフローを構成する各業務プロセスに関するデータは、プロセスフローデータを構成する各部に割り当てられて格納される。なお、1つのプロセスフロー例えば、ある企業からの受注から納品までの一連のプロセスフローに関するプロセスデータは、プロセスフローテーブルPTにおいて同一エントリすなわち、プロセステーブルPTにおける同一行に格納される。このような構成とすることにより、各プロセスデータ間の対応関係を定義することができる。ここで、主キー部とは、プロセスフローデータのうち、プロセスフローデータを一意に特定するためのデータである主キーデータが格納される部分である。本例においては、主キー部は、プロセスフロー番号とプロセスフロー明細番号とにより構成される。すなわち、本例においては、プロセスフロー番号とプロセスフロー明細番号との組み合わせが、各プロセスフローデータの識別子IDとなる。主キー部は、プロセスフローデータの初回登録時に更新される。なお、ここでのプロセスフローデータの初回登録時とは、プロセスフローデータにエントリデータ行が追加されるとき、例えば、あるプロセスフローに属するプロセスデータであって、対応する他のプロセスデータが未登録のプロセスデータが登録されるときを意味するものとする。また、ここでの更新とは、データの追加を含むものとする。なお、プロセスフロー番号とは、1つのプロセスフローデータすなわち、図2に示すプロセスフローテーブルPTにおける1列を特定するための識別子である。プロセスフロー番号は、所定の項目が同じプロセスデータ毎に付与される。本例においては、プロセスフロー番号は、プロセスフローデータにおけるタイプと受注先とが同じプロセスフローデータに対して同一の番号が付与される。また、プロセスフロー明細番号とは、同一のプロセスフロー番号が付与されたプロセスフローデータの中から特定のプロセスフローデータを特定するための識別子である。すなわち、例えば図2に示すプロセスフローテーブルPTは、プロセスフローのタイプ在庫売上における業務プロセス受注において、受注先T001から金額1200と2600の業務を受注したことを示すプロセスデータを含むプロセスフローデータを、それぞれプロセスフロー番号000001とプロセスフロー明細番号0010または0020の組み合わせにより一意に特定することができる。次いで、参照キー部とは、プロセスフローデータのうち、売上返品に対する元取引など、プロセスフローに関連する他のプロセスフローデータまたは、他のプロセスデータを特定するためのデータである参照キーデータが格納される部分である。本例においては、参照キー部は、参照番号と参照明細番号とにより構成される。参照キー部は、プロセスフローデータの初回登録時に更新される。なお、参照番号と参照明細番号には、それぞれ、プロセスフローに関連する他のプロセスフローのプロセスフロー番号とプロセスフロー明細番号とが格納される。ただし、新規取引の場合など、プロセスフローに関連する他のプロセスフローがない場合には、参照キー部には、同一エントリの主キー部と同じ値を示すデータがすなわち、参照番号にはプロセスフロー番号が、参照明細番号にはプロセスフロー明細番号がそれぞれ格納される。また、参照キー部が、プロセスフローに関連する他のプロセスデータを示す場合、参照キー部には、プロセスデータの種類を特定するためのデータがさらに設けられる。また、タイプ部とは、プロセスフローデータのうち、在庫売上やサンプル出荷など、プロセスフローの種類を示すデータであるタイプデータが格納される部分である。タイプ部は、プロセスフローデータの初回登録時に更新される。なお、プロセスフローの種類は、在庫売上やサンプル出荷に限られない。また、プロセスフローの種類毎にどのプロセスが必要なのかが予め決まっているものとするすなわち、プロセスフローの種類毎に含まれる業務プロセスの種類や数が異なる。なお、プロセスフローの他の種類については、後で複数提示する図9参照。また、ステータス部とは、プロセスフローデータのうち、プロセスフローの進捗を表すデータすなわち、プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであるステータスデータが格納される部分である。本例においては、ステータスデータは、プロセスフローが必要とする業務プロセスに対し、未済のものには0、既済のものには1が設定されることにより、各業務プロセスの進捗を示す。すなわち、例えば図2に示すように、在庫売上のプロセスフローであって、プロセスフローに含まれる業務プロセスが受注、出荷、出庫、出庫検収、および売上である場合に、業務プロセス受注に関するプロセス固有データ例えば、受注日が登録されたとする。この場合、ステータスデータは、売上に対応する部分が1になり、その他の部分は初期状態すなわち、0が設定された状態のままとなる。すなわち、本例におけるステータス部は、各業務プロセス毎に更新される。言い換えれば、ステータス部は、後述するプロセス固有データの入力のとき、具体的には、所定のステータス変更条件が満たされたことにより各業務プロセスが完了した判定されたときに更新される。なお、ステータス変更条件は特に限定されないが、本例においては、1つの業務プロセスに対応するプロセス固有データが全て入力されることがステータス変更条件として基幹業務サーバ200の所定の記憶領域に記憶されているものとする。なお、本例においては、異なる種類のプロセスフローが同一のテーブルに格納されるため、テーブルを構成する項目列項目のうち、特定のプロセスフローには不要なプロセスデータを格納する部分が生じる場合もある。この場合、プロセスフローテーブルにおいては、不要なプロセスデータを格納する部分が空データとなり、空データに対応するステータスデータには0が格納されるものとする。また、共通データ部とは、プロセスフローデータのうち、受注先や出荷先など、業務プロセスによらないデータすなわち、同一のプロセスフローに含まれる業務プロセス間で共通するデータである共通データが格納される部分である。共通データ部は、プロセスフローデータの初回登録時に更新される。また、プロセス固有データ部とは、プロセスフローデータのうち、受注日や各業務プロセスにおいて登録されるデータ例えば、納期必着やワレモノ割れ物注意などの注意事項を示すテキストデータなど、同一のプロセスフローに含まれる各業務プロセスに固有のデータであるプロセス固有データが格納される部分である。プロセス固有データ部は、各業務プロセス毎に更新される。よって、本例においては、プロセスフローデータのうち、業務プロセスによるものがプロセス固有データであり、業務プロセスによらないものが共通データであるといえる。以上が本例におけるプロセスフローデータに関する説明となるが、ここで、図2に示す各種用語の定義について簡単に説明する。先ず、受注とは、得意先から注文を受け、得意先との契約を結んだ状態を意味する。また、出荷指示とは、倉庫業者や物流担当者に商品を出荷する指示を行った状態を意味する。また、出庫とは、商品が倉庫から出荷され、移動が開始された状態を意味する。また、検収とは、得意先の検収が完了し、商品の所有権が得意先に移行した状態を意味する。また、売上とは、得意先の検収を確認し、得意先に対する債権金額が確定=債権を計上した状態を意味する。また、検収の用語は、納入品やサービスが、注文通りの仕様=注文通りの数量、色や形、品質になっているかを検査する業務や検収完了時、資産の所有権が移行するという意味でも用いられる。なお、財務会計上または、制度会計上やERPシステム上では、資産の所有権の移行タイミングを明確にするために、検収というイベントが出庫と区別して定義される。基幹業務サーバ200は、プロセスフローDB220およびその他DB230に格納された各種データを、所定の抽出条件に応じてCSVCommaSeparatedValues形式に変換してDWHサーバ300に送信する機能を有する。なお、本例においては、基幹業務サーバ200は、FTPFileTransferProtocolによりCSV形式にしたデータファイルをDWHサーバ300に転送する。DWHサーバ300は、例えば本システムのシステム管理者によって管理されるサーバであり、データウェアハウスを実現するための各種の機能を有する。ここで、データウェアハウスとは、時系列で蓄積された帳票データなどの業務データ本例においては、プロセスフローデータの中から各項目間の関連性を分析するシステムをいう。また、DWHサーバ300は、基幹業務サーバ200から転送されたCSV形式のファイルを所定のデータ形式に変換するなどして、所定の格納領域に各種データを登録する機能を有する。なお、DWHサーバ300は、データ形式の変換を行わず、CSV形式の状態から各格納領域に応じたデータを抽出する構成とされていてもよい。クライアント10,20は、CPU中央処理装置、ROM、RAM、および表示部などを備えた情報処理装置クライアント端末である。本例においては、クライアント10,20は、Webブラウザや表計算ソフトなど、帳票データを扱うために利用可能な各種アプリケーションを有しているものとする。また、本例においては、クライアント10,20は、例えばユーザによる操作入力に応じて、DWHサーバ300から必要な帳票データ本例においては、プロセスフローデータを取得するためのクエリ検索項目、検索キー、抽出キーなどを定義し、DWHサーバ300に送信する機能を有する。本例においては、クライアント10は、LANを介してDWHサーバ300と通信し、DWHサーバ300から取得したデータを所定の表計算ソフトによって表示部に出力する機能を有する。また、クライアント20は、インターネットを介してDWHサーバ300と通信し、DWHサーバ300から取得したデータをWebブラウザによって表示部に出力する機能を有する。なお、本例においては、クライアント10,20は、基幹業務サーバ200のプロセスフローDB220に記憶されるプロセスフローデータに基づいて、所定の形態を有する帳票を自己が備える表示部に出力する機能を有する。なお、統合基幹業務システム500の構成はこれに限定されず、例えば、クライアント10,20と基幹業務サーバ200とが、DWHサーバ300を介さずに直接データの送受信を行える構成とされていてもよい。すなわち、クライアント10,20が、プロセスフローDB220Bに直接アクセス可能な構成とされていてもよい。次に、統合基幹業務システム500における基幹業務サーバ200の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。図3は、基幹業務サーバ200が実行するデータベース更新処理の例を示すフローチャートである。データベース更新処理では、基幹業務サーバ200にてプロセスフローDB220を更新するための処理が実行される。データベース更新処理において、先ず、基幹業務サーバ200は、新たなプロセスフローデータ新規プロセスフローデータを取得したか否かを判定するステップS101。ここで、新規プロセスフローデータを取得していないと判定するとステップS101のN、基幹業務サーバ200は、後述するステップS103の処理に移行する。一方、新規プロセスフローデータを取得したと判定するとステップS101のY、基幹業務サーバ200は、取得したプロセスフローデータをプロセスフローテーブルPTに登録するステップS102。次いで、基幹業務サーバ200は、登録済みのプロセスフローデータに対応するプロセスデータすなわち、プロセスフローを構成する業務プロセスに関するデータを取得したか否かを判定するステップS103。ここで、登録済みのプロセスフローデータに対応するプロセスデータを取得していないと判定するとステップS103のN、基幹業務サーバ200は、その他DB230を参照し、取得したデータに対応する記憶領域を特定して、取得したデータを登録しステップS104、ステップS101の処理に移行する。一方、登録済みのプロセスフローデータに対応するプロセスデータを取得したと判定するとステップS103のY、基幹業務サーバ200は、プロセスフローテーブルPTの対応項目にプロセスデータを登録するステップS105。なお、基幹業務サーバ200による取得したプロセスデータが登録済みのプロセスデータである否かの判定は、取得したデータが有するプロセスフロー番号とプロセスフロー明細番号との組み合わせを有するプロセスフローデータがプロセスフローテーブルPTに格納されているか否かを判定することにより行う。そのため、本例においては、基幹業務サーバが取得するデータ業務の実行者により入力されたデータ、または業務アプリケーションプログラムにより作成されたデータに、主キー部を構成するデータすなわち、プロセスフロー番号とプロセスフロー明細番号が含まれることが必要となる。プロセスデータを登録すると、基幹業務サーバ200は、プロセスデータの登録によりプロセスフローデータに関する所定のステータス変更条件が満たされたか否かを判定するステップS106。ここで、プロセスデータが登録されたことに応じて所定のステータス変更条件が満たされていないと判定するとステップS106のN、基幹業務サーバ200は、ステップS101に移行する。一方、プロセスデータが登録されたことに応じて所定のステータス変更条件が満たされたと判定するとステップS106のY、基幹業務サーバ200は、満たされたステータス変更条件に基づいて、プロセスフローデータが含むステータスデータを更新しステップS107、ステップS101の処理に移行する。本例におけるデータベース更新処理は、例えば、基幹業務サーバ200の管理者による終了操作により終了する。また、データベース更新処理は、リアルタイムに実行される処理であってもよいし、特定の単位時間毎に実行されるバッチ処理であってもよい。また、例えば指定された期間だけリアルタイム処理を行うような、一部にリアルタイム性を有した処理準リアルタイム処理であってもよい。次に、本例の統合基幹業務システム500における基幹業務サーバ200とDWHサーバ300とクライアント10,20の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。図4は、基幹業務サーバ200と、DWHサーバ300と、クライアント10とが実行する帳票出力処理の例を示すフローチャートである。帳票出力処理では、基幹業務サーバ200が、DWHサーバ300を介してクライアント10に対しプロセスフローデータプロセスフローデータの一部または全部を提供することにより、クライアント10が備える表示画面に帳票を表示するための処理が実行される。なお、クライアント10とクライアント20では、通信ネットワークの種類が異なるだけなので、本例においてはクライアント10を用いる場合を例に説明を行なう。また、本例におけるDWHサーバ300は、基幹業務サーバ200とクライアント10とが通信を行うための補助例えば、クライアントの認証などを行うだけなので、以下DWHサーバ300の動作についての説明は省略する。帳票出力処理において、先ず、クライアント10は、例えばクライアント10のユーザAによる操作入力に応じて、検索キー入力画面要求を基幹業務サーバ200に送信するステップS301。検索キー入力画面要求を受信すると、基幹業務サーバ200は、受信した検索キー入力画面要求に応じた検索キー入力画面を送信するステップS201。検索キー入力画面を受信すると、クライアント10は、自己が備える表示部の表示画面に検索キー入力画面を表示するステップS302。図5は、検索キー入力画面の例を示す説明図である。図5に示すように、検索キー入力画面には、プルダウン形式で、プロセスフローテーブルPTに設定された項目が選択可能に表示される検索項目表示領域11と、ユーザAによる検索キーの入力を受け付ける検索キー入力領域12と、表示部に出力される表示画面を他の表示画面に切替える要求を受け付ける戻るボタン13と、検索項目と検索キーとによるプロセスフローデータの検索要求を受け付ける検索ボタン14とが設けられる。クライアント10は、例えばマウス操作により操作可能なカーソルPによる検索項目の選択を受け付けると、選択された検索項目を仮選択状態とする。そして、検索ボタン14の選択を受け付けると、クライアント10は、仮選択状態にある検索項目の選択本選択を受け付けたものと判定してステップS303、選択された検索項目と検索キー入力領域12に入力された検索キーとを基幹業務サーバ200に送信するステップS304。検索項目と検索キーとを受信すると、基幹業務サーバ200は、プロセスフローテーブルPTに登録されたプロセスフローデータのうち、受信した検索項目が示す項目すなわち、プロセスフローテーブルPTにおける列項目に、受信した検索キーと同一または、受信した検索キーを含む文字列が登録されたプロセスフローデータを検索するステップS202。なお、このとき検索キーが空データである場合には、基幹業務サーバ200が、受信した検索項目にプロセスデータを有するすなわち、受信した検索項目に空データ以外のデータが格納されたプロセスフローデータを全て検索する構成としてもよいし、検索エラー通知をクライアント10に送信する構成としてもよい。プロセスフローデータを検索すると、基幹業務サーバ200は、検索したプロセスフローデータをクライアント10に送信しステップS203、ここでの処理を終了する。一方、プロセスフローデータを受信すると、クライアント10は、受信したプロセスフローデータに基づいて、自己が備える表示部の表示画面に帳票表示画面を表示するステップS305。図6は、帳票表示画面の例を示す説明図である。図6に示すように、帳票表示画面には、プロセスフローデータに基づいた帳票を表示する帳票表示領域21と、帳票ステータス表示領域22と、戻るボタン23と、変更ボタン24とが設けられる。なお、クライアント10は、例えばクライアント10に備えられたキーボードなどの操作に応じて帳票表示領域21に表示される帳票の縮尺を変更する。ここで、帳票表示領域21には、所定の表示形態でプロセスフローデータの一部または全部が表示される。なお、本例においては、所定の表示形態でプロセスフローデータの一部または全部を表示するための情報が、基幹業務サーバ200により作成されて、例えば帳票出力処理におけるステップS203のタイミングで、クライアント10に送信されるものとする。なお、クライアント10が、自己が備える記憶装置に記憶された情報に基づいて、受信したプロセスフローデータの一部または全部を所定の表示形態で帳票表示領域21に表示する構成としてもよい。また、帳票ステータス表示領域22は、帳票表示領域21に表示される帳票の種類または、状況。以下、ステータスという。を表示する領域である。なお、帳票のステータスとしては、例えば、受注伝票、出庫伝票、検収伝票、および請求書など、種々のものが考えられる。また、戻るボタン23は、表示画面を検索キー入力画面に戻す旨の要求を受け付けるためのボタンである。また、変更ボタン24は、帳票表示領域21の表示内容を変更する旨の要求を受け付けるためのボタンである。以下、帳票表示領域21の表示内容の変更処理に関して説明する。帳票表示画面を表示すると、クライアント10は、ユーザAによる帳票ステータス変更要求を受け付けたか否かを判定するステップS306。本例においては、クライアント10は、先ず、ユーザAによる帳票ステータス表示領域22の選択を受け付ける。そして、例えばマウス操作により操作可能なカーソルPによる帳票ステータス表示領域22の選択を受け付けると、クライアント10は、表示可能な帳票の形態を示す帳票ステータス名称のリストを、例えばプルダウン形式で選択可能に表示する。なお、ここで表示する帳票ステータス名称については、基幹業務サーバ200からプロセスフローデータと共に受信しているものとする。具体的には、基幹業務サーバ200は、予め所定の記憶領域に記憶された帳票の形態に関するデータ帳票形態データとプロセスフローデータの状態すなわち、プロセスフローテーブルPTの各列項目の入力状態とに基づいて、表示可能な帳票の形態を示す帳票ステータス名称を特定する。すなわち、例えばクライアント10に送信するプロセスフローデータのタイプが在庫売上であり、プロセス固有データ部に業務プロセス受注に関するプロセスデータしか登録されていない場合には、基幹業務サーバ200は、帳票ステータス名称として受注伝票のみを特定する。また、業務プロセス受注に関するプロセスデータの他、業務プロセス出庫に関するプロセスデータが登録されている場合、基幹業務サーバ200は、帳票ステータス名称として、受注伝票と出庫伝票とを特定する。図7は、プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。図7において、画像101~104が、それぞれプロセスフローデータに基づいて帳票表示領域21に表示され得る帳票具体的には、伝票の形態であるとする。なお、画像101~104は、帳票ステータスの遷移について説明するための説明図であり、各種帳票としての役割を果たすための具体的記載例を示すものではない。ここで、画像104を例にして説明すると、画像104における領域111が帳票ステータス名称を、領域112がプロセスフローのタイプを、領域113がプロセスフローデータに含まれるプロセスデータの業務プロセスの名称をそれぞれ示す領域本例においては、文字列表示領域であるものとする。なお、本例においては、プロセスフローデータに含まれるプロセスデータの種類に対応した帳票ステータス名称を領域111に表示している。この場合、図7における画像101から画像104への遷移が示すように、1つのプロセスフローデータに対して各業務プロセスに応じたプロセスデータが登録されていく度に、帳票ステータス名称すなわち、プロセスフローデータに基づいて表示可能な帳票の形態の種類が増えていくことになる。これは、次の種類の帳票があるかないかではなく、プロセスフローデータの状態に応じて帳票のステータスが上がっていくすなわち、表示可能な帳票の種類が増えていくことを意味する。以下、帳票出力処理におけるステップS305の処理の前に、クライアント10が、業務プロセス受注,出庫を含むプロセスフローデータを受信した場合を例にして説明を続ける。なお、本例においては、ステップS305の処理にて、クライアント10が、受信したプロセスフローデータが示すプロセスフローにおいて業務プロセス出庫よりも上位に位置する業務プロセス受注に対応する帳票ステータス名称受注伝票に対応する帳票を、帳票表示領域21に表示していたものとする図6参照。帳票ステータス変更要求の受付判定処理ステップS306において、ユーザAによる帳票ステータス変更要求を受け付けていないと判定するとステップS306のN、クライアント10は、後述するステップS308の処理に移行する。一方、ユーザAによる帳票ステータス変更要求を受け付けたと判定するとステップS306のY、クライアント10は、帳票表示領域21に、受け付けた変更要求に応じた帳票を表示するステップS307。本例においては、クライアント10が、ユーザAによる業務プロセス出庫に対応する帳票ステータス名称出庫伝票の選択を受け付けて、業務プロセス出庫に対応する帳票出庫伝票を帳票表示領域21に表示するものとする。なお、この場合、クライアント10は、帳票ステータス表示領域22に、帳票ステータス名称出庫伝票を表示する。帳票ステータス変更要求に応じた帳票を表示すると、クライアント10は、帳票出力処理を終了するか否かを判定するステップS308。ここで、帳票出力処理を終了しないと判定するとステップS308のN、クライアント10は、ステップS306の処理に移行する。一方、例えばユーザAによる所定の終了操作を受け付けたことにより帳票出力処理を終了するものと判定するとステップS308のY、クライアント10は、ここでの処理を終了する。以上に説明したように、上述した実施の形態では、データベース例えば、プロセスフローDB220が、複数の業務プロセスを含むプロセスフロー例えば、タイプ在庫売上のプロセスフローに関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルPTを備え、プロセスフローデータが、ステータスデータと、共通データと、プロセス固有データとを含み、ステータスデータが、プロセスフローに含まれる複数の業務プロセス例えば、受注、出荷指示、出庫、出庫検収、売上それぞれの進捗状況を示すデータであり、共通データが、同一のプロセスフローに含まれる業務プロセス間で共通するデータ例えば、受注先や金額などを示すデータであり、プロセス固有データが、同一のプロセスフローに含まれる各業務プロセスに固有のデータ例えば、受注日や受注テキストであり、ステータスデータが、プロセス固有データが更新されたことに応じて更新される例えば、プロセス固有データが追加されたことに応じて、対応するステータスデータが0から1に変更される構成としているので、ERPシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。すなわち、データ更新時に発生するI/Oデータ入出力データの量を少なくすることができるようになる。図8は、上述した基幹業務サーバ200が実行するデータベース更新処理の有用性について説明するための説明図である。図8Aは、最初のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。ここで、最初に入力するプロセスデータの種類すなわち、業務プロセスの種類は特に限定されない。また、従来型とは、図10に示したように、各業務プロセス毎にテーブルを備えたデータベースを意味する。また、データ量の差とは、厳密な数値を示すものではなく、従来型テーブルに格納されたデータを更新する場合と新規型プロセスフローテーブルすなわち、プロセスフローテーブルPT、図2参照。以下、従来型と比較する場合には適宜新規型と呼ぶ。に格納されたデータを更新する場合とを比較した場合に、新規型の方が扱うデータ量が多くなる場合をプラス、新規型の方が扱うデータ量が少なくなる場合を-マイナス、新規型と従来型とで扱うデータ量が同じとみなせる場合を0とする。この場合、最初のプロセスデータの入力時においては、ステータス部の更新が必要である分だけ新規型のほうが扱うデータ量が多くなる。ただし、ステータス部のデータ量は小さいので、実質的には従来型と新規型とで、I/Oデータ入力データと出力データの量に大きな差はないといえる。一方、図8Bは、2つ目のプロセス以降のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。すなわち、例えば、主キー部、参照キー部、タイプ部、ステータス部、共通データ部、およびプロセス固有データ部の一部例えば、業務プロセス受注に応じたプロセス固有データ受信日,受注テキストがプロセスフローデータテーブルPTに入力済みのプロセスフローに含まれる業務プロセスに応じたプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。なお、従来型は、入力済みのプロセスデータとの対応関係を定義するために、例えば受注テーブルに登録されたプロセスデータ受注データに対応する他のプロセスデータ例えば、業務プロセス出荷指示に対応するプロセスデータ出荷指示データを入力する場合には、出荷指示データとして、本例における主キー部、参照キー部、タイプ部、共通データ部、およびプロセス固有データ部に対応するデータ図2と図10参照の他、対応する受注データを示す受注番号と受注明細とを入力する必要がある。この場合、2つ目のプロセス以降のプロセスデータの入力時においては、ステータス部以外の全ての部分を必要とする従来型に比べて、新規型は、ステータス部とプロセス固有データ部のみを更新するので、I/Oデータの量が少なくなる。よって、新規型の方が従来型よりもI/Oデータの量が少なくなり、システムのパフォーマンス上、有利となる。すなわち、データベースのI/Oが削減することができるようになるため、書き込み量の減少、データベース全体の容量の縮減、およびデータの検索処理に要する処理負荷の軽減を実現することができるようになる。なお、検索処理に要する処理負荷の軽減に関しては、プロセスプロセスデータが複数のテーブルにまたがっていないことも1つの要因となる。また、新規型では、プレセスデータの入力順序をある程度、順不同にできるというメリットがある。すなわち、例えばタイプ在庫売上で考えると、従来型の場合、プロセスフローの順序が、受注、出荷指示、出庫、出庫検収、売上の順に限定され、順序を変えることができない。これは、従来型のテーブル構造では、業務プロセス間の関係を、後の業務プロセスのデータに前の業務プロセスの主キーを持たせることで表現しているためである例えば、出荷指示テーブルにおける受注番号と受注明細。図10参照。一方、新規型のテーブル構造では、関係する業務プロセスのデータは、同一のエントリすなわち、同一テーブルの同一列に格納される。このため、業務プロセス間の前後関係に制約を持たず、業務プロセスの順序を柔軟に組み替えることができるようになる。すなわち、例えば実際の業務の順序が出荷指示の後に受注であった場合に、プロセスデータの入力順序を、実際の業務の順序に沿った形にすることができるようになる。そのため、進捗管理上言い換えれば、内部統制上、従来型に対して有利である。なお、具体的には、現在の卸売業界の業務順序が出荷指示の後に受注である。また、新規型では、プロセスフローの進捗の照会に要する負荷を軽減させることができるようになる。すなわち、プロセスフローがどこまで進んでいるか確認する場合、従来型のテーブル構造では、開始伝票のテーブルから順に、最終伝票のテーブルまでのすべてのテーブルの登録状況を確認する必要がある。例えば、タイプ在庫売上を例に考えると、受注、出荷指示、出庫、出庫検収、請求の5つのテーブルを確認する必要がある。一方、新規型のテーブル構造では、プロセスフローの進捗状況をステータス部として持っているため、1つのテーブル、1つのエントリを照会するだけで進捗の確認ができるようになる。これは、進捗状況の照会画面を使用もしくは開発する際に、有利である。また、上述した実施の形態では、データベース例えば、プロセスフローDB220が、プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバ例えば、基幹業務サーバ200に備えられ、プロセスフローデータ管理サーバが、クライアント端末例えば、クライアント10,20からの要求に応じて、プロセスフローデータの一部又は全部をクライアント端末に提供する構成としているので、業務フローに関するデータ例えば、帳票の作成に必要な帳票情報を示すプロセスフローデータの提供に要する処理負荷が従来に比べて軽減されたシステムを構築することができるようになる。なお、上述した実施の形態では特に言及していないが、データベース例えば、プロセスフローDB220が、プロセスフローの進捗状況の判定条件を示すデータである進捗状況判定条件データが登録された進捗状況判定条件テーブルを備え、プロセスフローデータ管理サーバ例えば、基幹業務サーバ200が、進捗状況判定条件に基づいてステータスデータ例えば、プロセスフローテーブルPTにおけるステータス部に格納されたデータ。図2参照。が進捗状況判定条件を満たしているか判定し、満たしていると判定した進捗状況判定条件に応じた進捗状況をクライアント端末例えば、クライアント10,20に報知する構成としてもよい。図9は、進捗状況判定条件テーブルに格納された進捗状況判定条件データの格納状態の例を示す説明図である。図9に示すように、本例における進捗状況判定条件データは、プロセスフローのタイプと、プロセスフローのタイプに応じた進捗状況判定条件とを含む。ここで、プロセスフローのタイプには、上述した在庫売上の他、サンプル出荷、サービス売上、名義変更売上、名義変更出荷、売上返品元取引参照あり、売上返品元取引参照なし、売上金額調整プラス、売上金額調整マイナスなど、業務プロセスの異なる種々のものが考えられる。また、進捗状況判定条件とは、プロセスフローの進捗状況の判定基準を示すものであり、本例においては、プロセスフローのタイプ毎に必要な業務プロセス例えば、受注、出荷指示、出庫、出庫検収、および売上のうち予めタイプ別に設定された業務プロセスに1が設定されているものとする。基幹業務サーバ200は、プロセスフローテーブルPTに格納されたプロセスフローデータのうち、ステータス部の状態が進捗状況判定条件データと一致した場合に、プロセスフローデータのエントリが完了の状態にあると判定しすなわち、プロセスフローデータが示すプロセスフローが完了したと判定し、その旨を所定のクライアント例えば、クライアント10,20に報知するための処理報知処理を行う。このような構成とすることにより、業務遂行状況の判定が可能なシステムを構築することができるようになる。特に、プロセスフローデータが含むステータスデータと進捗状況判定条件データとを比較するだけで業務遂行状況の判定処理が可能となるため、複数のテーブルに格納されたデータの入力状況を参照する必要がある従来のものと比べて、業務遂行状況の判定に要する処理負荷を軽減させることができる。なお、進捗状況の判定処理または報知処理の開始時機は、クライアント端末からの要求があったときであってもよいし、予め設定された時機であってもよい。また、上述した進捗状況判定条件テーブルの例では、進捗状況判定条件データが、プロセスフローが完了したか判定するための完了条件を含む構成としているので、一連の業務の完了判定が容易に可能なシステムを構築することができるようになる。なお、進捗状況判定条件データは、プロセスフローが完了の状態にあると判定するためのものに限定されず、例えば、50完了の状態にあると判定するためのデータが含まれる構成としてもよい。また、進捗状況判定条件データが、最初のプロセスデータの入力時から所定時間が経過するまでに入力されるべきであるプロセスデータの種類を示す構成としてもよい。また、進捗状況判定条件テーブルに、上述したような入力されるべきデータが全て入力されたかの判定機能だけでなく、入力されるべきではないデータが入力されないようにデータの入力を制限する機能を持たせる構成としてもよい。この場合、例えば、基幹業務サーバ200が、プロセスフローテーブルPTを更新するときに、追加するプロセスデータがプロセス固有データである場合に、追加するプロセス固有データの種類と進捗状況判定条件テーブルとを比較して、追加するプロセス固有データの種類が進捗状況条件テーブルに1が設定されていない業務プロセスに対応するものである場合にはプロセスフローテーブルの更新をしない構成とすればよい。"