JP5386639B2 - データベース、データ管理サーバ、およびデータ管理プログラム - Google Patents

Description

本発明は、ＥＲＰシステムにて利用可能なデータベース、このデータベースを備えるデータ管理サーバ、およびデータ管理サーバに搭載されるデータ管理プログラムに関する。

従来から、企業における基幹業務システムを構築するためのパッケージソフトウェアとして、ＥＲＰ（Enterprise Resource Planning）（または、ＥＲＰパッケージ）と呼ばれるものが利用されている。

このＥＲＰが搭載されたシステムとして、企業における販売管理、購買管理、在庫管理、生産管理、財務会計、管理会計といった基幹業務をリアルタイムに連携させ、各業務に関する情報を一元的に管理することを可能としたものが広く知られている。

このようなシステム（ＥＲＰシステム、または統合基幹業務システム）には、例えば、経営資源の情報管理を行い、予め定められた第１のデータフォーマットによる情報の通信を行う統合業務システムに、第１のデータフォーマットとは異なる第２のデータフォーマットによる情報の通信を行う複数の情報装置とに接続されたデータ変換装置であって、統合業務システムから出力される第１のデータフォーマットによる情報の入力を受け付け、受け付けた情報を第２のデータフォーマットに変換して情報装置に送信するデータ変換装置を組み込む構成とすることにより、システムの利便性を高めようとするものもがある（特許文献１参照）。

特開２００９―０９９０７０号公報

しかしながら、従来のＥＲＰシステムでは、各業務プロセスにおいて取得されるデータ（ユーザにより入力されるデータと各種データから算出されるデータとを含む）を、それぞれ専用のデータテーブル（テーブル）に登録し、管理している。すなわち、従来のＥＲＰシステムにおいては、受注や出荷指示などの入力プロセス毎に、更新するテーブルが異なる。なお、「入力プロセス」とは、各業務プロセスにおいてＥＲＰシステムの管理者などが取得（または決定）した各種データを、各テーブルに入力する処理を意味する。

図１２は、従来のＥＲＰシステムにおけるテーブル構成の例について説明するための説明図である。例えば、複数の業務プロセスにより構成される業務フロー（プロセスフロー）が「在庫売上」を示すものである場合、入力プロセスは、受注、出荷指示、出庫、検収、および売上の５つとなる。この場合、「在庫売上」のプロセスフローに関するデータを格納するテーブルは、例えば図１２（Ａ）から図１２（Ｅ）に示すように、入力プロセス毎にそれぞれ、受注テーブル、出荷指示テーブル、出庫テーブル、検収テーブル、および売上テーブルの５つとなる。

すなわち、従来のＥＲＰシステムでは、入力プロセス毎に更新するテーブルが異なっていた。そのため、同一のプロセスフローに属する複数の業務プロセス間の対応付けは、各業務プロセスに関するデータ（プロセスデータ）に対して識別子（図１２においては、出荷指示テーブルにおける受注番号と受注明細や、出庫テーブルにおける出荷指示番号と出荷指示明細など）を付与することにより行われていた。

そのため、従来のＥＲＰシステムでは、１つの入力プロセスに対して、入力プロセスの種類に応じたテーブルの特定と、対応する他のプロセスデータの識別子の入力とが必要となっていた。すなわち、例えば図１２に示す場合に、受注番号「Ａ００００１」と受注明細番号「００１０」とで特定されるプロセスデータ（すなわち、受注テーブルにおいて受注番号「Ａ００００１」と受注明細番号「００１０」と同一列に格納された各種データ）に関連する業務プロセス「出荷指示」に関するプロセスデータをＥＲＰシステムが備えるデータベースに登録する場合、業務プロセス「出荷指示」に関するプロセスデータとして、プロセスデータを特定するための出荷指示番号と出荷指示明細番号、業務プロセスの種類を示すタイプ、および業務プロセスの内容を示すデータ（例えば、受注先、数量、金額、出荷指示日、出荷テキストなど）と共に、受注番号「Ａ００００１」と受注明細番号「００１０」とを出荷指示テーブルに登録する必要があった。これは、複数のテーブルに一部同一のデータ（例えば、受注先や数量、金額など）が登録されてしまうことなど、効率的なデータ処理の観点からみて問題があった。

また、従来のＥＲＰシステムでは、各種テーブルに格納された各種データを用いてユーザの要求に応じた帳票を作成しようとする場合、プロセスデータの識別子を辿って必要なプロセスデータを検索し、それぞれ別個に取得する必要があるため、プロセスフローが多数の業務プロセスを含む場合、プロセスフローに関する帳票を出力するために要する処理負荷が過大になってしまうという問題があった。

本発明は、上述した問題を解消し、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることをできるようにすることを目的とする。

本発明のデータベースは、クライアント端末に対して各種データを提供するデータ管理サーバに備えられ、当該データを格納するデータベースであって、前記データベースは、複数の業務プロセスを含むプロセスフロー毎に発生する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルと、前記プロセスフローデータの更新条件を示す更新条件データが登録される更新条件テーブルとを備え、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記ステータスデータは、前記プロセス固有データが更新されたことに応じて前記データ管理サーバにより更新され、前記更新条件データは、前記ステータスデータの状態を示すデータであり、前記データ管理サーバは、前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付手段と、前記更新条件データに基づいて、前記プロセスデータ受付手段により受け付けられたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定手段と、該登録判定手段により前記プロセスデータを登録するものと判定されたことに応じて、前記プロセスフローテーブルに登録されたプロセスフローデータを更新するプロセスフローデータ更新手段と、前記登録判定手段により前記プロセスデータを登録しないと判定されたことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定手段と、該非充足更新条件特定手段により特定された非充足更新条件を前記クライアント端末に報知する報知手段と、所定のタイミングで、前記非充足更新条件として特定された更新条件が満たされたか判定する充足判定手段とを含み、前記プロセスフローデータ更新手段は、前記充足判定手段により前記非充足更新条件として特定された更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録することを特徴とする。

上記の構成としたことで、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。

前記データ管理サーバは、クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段を含む構成とされていてもよい。

また、本発明のデータ管理サーバは、クライアント端末に対して各種データを提供するデータ管理サーバであって、複数の業務プロセスを含むプロセスフロー毎に発生する各種データを含むプロセスフローデータと、該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段と、前記プロセスフローの進捗状況に応じて前記プロセスフローデータを更新するプロセスフローデータ更新手段と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段と、前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付手段と、前記更新条件データに基づいて、前記プロセスデータ受付手段により受け付けられたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定手段と、前記登録判定手段により前記プロセスデータを登録しないと判定されたことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定手段と、該非充足更新条件特定手段により特定された非充足更新条件を前記クライアント端末に報知する報知手段と、所定のタイミングで、前記非充足更新条件として特定された更新条件が満たされたか判定する充足判定手段とを含み、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記更新条件データは、前記ステータスデータの状態を示すデータであり、前記プロセスフローデータ更新手段は、前記登録判定手段により前記プロセスデータを登録するものと判定されたことに応じて、前記プロセスフローテーブルに登録されたプロセスフローデータを更新し、前記充足判定手段により前記非充足更新条件として特定された更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録することを特徴とする。

さらに、本発明のデータ管理プログラムは、クライアント端末に対して各種データを提供するようにデータ管理サーバに動作制御させるためのデータ管理プログラムであって、
前記データ管理サーバに、複数の業務プロセスを含むプロセスフローの進捗状況に応じて前記プロセスフロー毎に発生する各種データを含むプロセスフローデータと該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供処理と、前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付処理と、前記更新条件データに基づいて、前記プロセスデータ受付処理にて受け付けたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定処理と、前記登録判定処理にて前記プロセスデータを登録しないと判定したことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定処理と、該非充足更新条件特定処理にて特定した非充足更新条件を前記クライアント端末に報知する報知処理と、所定のタイミングで、前記非充足更新処理にて特定した更新条件が満たされたか判定する充足判定処理とを実行させ、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記更新条件データは、前記ステータスデータの状態を示すデータであり、前記プロセスフローデータ更新処理では、前記登録判定処理にて前記プロセスデータを登録するものと判定したことに応じて、前記プロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新する処理と、前記充足判定処理にて前記非充足更新条件として特定した更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録する処理とを実行させるためのものである。

本発明によれば、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。

本発明の一実施の形態における統合基幹業務システムの構成例を示すブロック図である。 プロセスフローデータの格納状態の例を示す説明図である。 更新条件データの格納状態の例を示す説明図である。 データベース更新処理の例を示すフローチャートである。 帳票出力処理の例を示すフローチャートである。 プロセスフローデータ更新要求入力画面の例を示す説明図である。 更新エラー通知表示画面の例を示す説明図である。 帳票表示画面の例を示す説明図である。 プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。 データベース更新処理の有用性について説明するための説明図である。 進捗状況判定条件データの格納状態の例を示す説明図である。 従来のＥＲＰシステムにおけるテーブル構成の例について説明するための説明図である。

以下、本発明の一実施の形態の例について図面を参照して説明する。

図１は、本発明の一実施の形態に係る統合基幹業務システム５００の構成例を示すブロック図である。図１に示すように、統合基幹業務システム５００は、基幹業務サーバ２００と、データウェアハウスサーバ（ＤＷＨサーバ）３００と、クライアント１０と、クライアント２０とを含む。統合基幹業務システム５００を構成する各要素は、それぞれ通信ネットワークにより接続される。

本例においては、基幹業務サーバ２００とＤＷＨサーバ３００とは、専用回線５１により接続されているものとする。また、クライアント１０は、ＬＡＮ（Local Area Network）５２によりＤＷＨサーバ３００と接続されている。また、クライアント２０は、インターネット５３によりＤＷＨサーバ３００と接続されている。

基幹業務サーバ２００は、例えば統合基幹業務システム５００の管理者によって管理されるサーバであり、各種業務に関する帳票情報など、各種業務プロセスにおける情報を示すデータであるプロセスデータを管理するための各種機能を有する。なお、本例における基幹業務サーバ２００は、ＯＳ（Operating System）やリレーショナルデータベース（リレーショナルＤＢ）を備えた一般的な情報処理装置によって構成される。

ここで、帳票とは、帳簿や伝票類の総称である。また、帳簿とは、金銭や品物の出納に関する事項が記入されるものであり、伝票とは、帳簿を作成する際の基となるデータであり業務上の取引等の証拠となるものである。なお、基幹業務サーバ２００が、例えば、各種伝票の作成に用いる伝票情報のみを示すプロセスデータを扱う構成としてもよい。

また、本例における基幹業務サーバ２００は、図１に示すように、業務アプリケーションプログラムＤＢ２１０と、プロセスフローＤＢ２２０と、一般的な基幹業務サーバとしての機能を実現するために必要な各種データ（例えば、業務アプリケーションプログラムＤＢ２１０に格納される各種プログラムが利用するデータ）を格納するその他ＤＢ２３０とを備えている。なお、その他ＤＢ２３０については、本発明に特に関係しない部分であるため、詳しい説明は省略する。

業務アプリケーションプログラムＤＢ２１０は、各種業務に用いられるプログラムを記憶する記憶媒体である。業務アプリケーションプログラムＤＢ２１０に記憶されるプログラムとしては、販売業務管理プログラム、購買業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。

プロセスフローＤＢ２２０は、業務アプリケーションプログラムＤＢ２１０に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ（または帳票データ）により構成されるプロセスフローデータを記憶する記憶媒体である。本例においては、プロセスフローＤＢ２２０において、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータがプロセスフローテーブルＰＴに格納される場合について説明する。また、本例においては、基幹業務サーバ２００が、プロセスフロー毎に発生するプロセスフローデータを１つのプロセスフローテーブルＰＴにて一元管理する場合について説明する。

なお、基幹業務サーバ２００が、プロセスフローデータを、例えば、後述するタイプ毎に、あるいは後述する共通データの内容の一部（例えば、受注先など）が同じもの毎に、複数のテーブルで管理する構成としてもよい。

図２は、プロセスフローＤＢ２２０におけるプロセスフローデータの格納状態の例を示す説明図である。図２に示すように、本例におけるプロセスフローデータは、主キー部と、参照キー部と、タイプ部と、ステータス部と、共通データ部と、プロセス固有データ部とを含む。なお、プロセスフローデータの各部に対応する項目（すなわち、プロセスフローテーブルＰＴにおける各列項目）が、それぞれ、プロセスフローデータを構成するプロセスデータの種類を示す。すなわち、プロセスフローを構成する各業務プロセスに関するデータは、プロセスフローデータを構成する各部に割り当てられて格納される。なお、１つのプロセスフロー（例えば、ある企業からの受注から納品までの一連のプロセスフロー）に関するプロセスデータは、プロセスフローテーブルＰＴにおいて同一エントリ（すなわち、プロセステーブルＰＴにおける同一行）に格納される。このような構成とすることにより、各プロセスデータ間の対応関係を定義することができる。

ここで、「主キー部」とは、プロセスフローデータのうち、プロセスフローデータを一意に特定するためのデータである主キーデータが格納される部分である。本例においては、主キー部は、プロセスフロー番号とプロセスフロー明細番号とにより構成される。すなわち、本例においては、プロセスフロー番号とプロセスフロー明細番号との組み合わせが、各プロセスフローデータの識別子（ＩＤ）となる。主キー部は、プロセスフローデータの初回登録時に更新される。なお、ここでの「プロセスフローデータの初回登録時」とは、プロセスフローデータにエントリ（データ行）が追加されるとき、例えば、あるプロセスフローに属するプロセスデータであって、対応する他のプロセスデータが未登録のプロセスデータが登録されるときを意味するものとする。また、ここでの「更新」とは、データの追加を含むものとする。

なお、「プロセスフロー番号」とは、１つのプロセスフローデータ（すなわち、図２に示すプロセスフローテーブルＰＴにおける１列）を特定するための識別子である。プロセスフロー番号は、所定の項目が同じプロセスデータ毎に付与される。本例においては、プロセスフロー番号は、プロセスフローデータにおけるタイプと受注先とが同じプロセスフローデータに対して同一の番号が付与される。

また、「プロセスフロー明細番号」とは、同一のプロセスフロー番号が付与されたプロセスフローデータの中から特定のプロセスフローデータを特定するための識別子である。すなわち、例えば図２に示すプロセスフローテーブルＰＴは、プロセスフローのタイプ「在庫売上」における業務プロセス「受注」において、受注先「Ｔ００１」から金額「１２００」と「２６００」の業務を受注したことを示すプロセスデータを含むプロセスフローデータを、それぞれプロセスフロー番号「０００００１」とプロセスフロー明細番号「００１０」または「００２０」の組み合わせにより一意に特定することができる。

次いで、「参照キー部」とは、プロセスフローデータのうち、売上返品に対する元取引など、プロセスフローに関連する他のプロセスフローデータ（または、他のプロセスデータ）を特定するためのデータである参照キーデータが格納される部分である。本例においては、参照キー部は、参照番号と参照明細番号とにより構成される。参照キー部は、プロセスフローデータの初回登録時に更新される。

なお、参照番号と参照明細番号には、それぞれ、プロセスフローに関連する他のプロセスフローのプロセスフロー番号とプロセスフロー明細番号とが格納される。ただし、新規取引の場合など、プロセスフローに関連する他のプロセスフローがない場合には、参照キー部には、同一エントリの主キー部と同じ値を示すデータが（すなわち、参照番号にはプロセスフロー番号が、参照明細番号にはプロセスフロー明細番号がそれぞれ）格納される。また、参照キー部が、プロセスフローに関連する他のプロセスデータを示す場合、参照キー部には、プロセスデータの種類を特定するためのデータがさらに設けられる。

また、「タイプ部」とは、プロセスフローデータのうち、在庫売上やサンプル出荷など、プロセスフローの種類を示すデータであるタイプデータが格納される部分である。タイプ部は、プロセスフローデータの初回登録時に更新される。なお、プロセスフローの種類は、在庫売上やサンプル出荷に限られない。また、プロセスフローの種類毎にどのプロセスが必要なのかが予め決まっているものとする（すなわち、プロセスフローの種類毎に含まれる業務プロセスの種類や数が異なる）。なお、プロセスフローの他の種類については、後で複数提示する（図１１参照）。

また、「ステータス部」とは、プロセスフローデータのうち、プロセスフローの進捗を表すデータ（すなわち、プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータ）であるステータスデータが格納される部分である。本例においては、ステータスデータは、プロセスフローが必要とする業務プロセスに対し、未済のものには「０」、既済のものには「１」が設定されることにより、各業務プロセスの進捗を示す。すなわち、例えば図２に示すように、「在庫売上」のプロセスフローであって、プロセスフローに含まれる業務プロセスが「受注」、「出荷」、「出庫」、「出庫検収」、および「売上」である場合に、業務プロセス「受注」に関するプロセス固有データ（例えば、受注日）が登録されたとする。この場合、ステータスデータは、「売上」に対応する部分が「１」になり、その他の部分は初期状態（すなわち、「０」が設定された状態）のままとなる。

すなわち、本例におけるステータス部は、各業務プロセス毎に更新される。言い換えれば、ステータス部は、後述するプロセス固有データの入力のとき、具体的には、所定のステータス変更条件が満たされたことにより各業務プロセスが完了した判定されたときに更新される。なお、ステータス変更条件は特に限定されないが、本例においては、「１つの業務プロセスに対応するプロセス固有データが全て入力されること」がステータス変更条件として基幹業務サーバ２００の所定の記憶領域に記憶されているものとする。

なお、本例においては、異なる種類のプロセスフローが同一のテーブルに格納されるため、テーブルを構成する項目（列項目）のうち、特定のプロセスフローには不要なプロセスデータを格納する部分が生じる場合もある。この場合、プロセスフローテーブルにおいては、不要なプロセスデータを格納する部分が空データとなり、空データに対応するステータスデータには「０」が格納されるものとする。

また、「共通データ部」とは、プロセスフローデータのうち、受注先や出荷先など、業務プロセスによらないデータ（すなわち、同一のプロセスフローに含まれる業務プロセス間で共通するデータ）である共通データが格納される部分である。共通データ部は、プロセスフローデータの初回登録時に更新される。

また、「プロセス固有データ部」とは、プロセスフローデータのうち、受注日や各業務プロセスにおいて登録されるデータ（例えば、「納期必着」や「ワレモノ（割れ物注意）」などの注意事項を示すテキストデータ）など、同一のプロセスフローに含まれる各業務プロセスに固有のデータであるプロセス固有データが格納される部分である。プロセス固有データ部は、各業務プロセス毎に更新される。よって、本例においては、プロセスフローデータのうち、業務プロセスによるものが「プロセス固有データ」であり、業務プロセスによらないものが「共通データ」であるといえる。

以上が本例におけるプロセスフローデータに関する説明となるが、ここで、図２に示す各種用語の定義について簡単に説明する。

先ず、「受注」とは、得意先から注文を受け、得意先との契約を結んだ状態を意味する。また、「出荷指示」とは、倉庫業者や物流担当者に商品を出荷する指示を行った状態を意味する。また、「出庫」とは、商品が倉庫から出荷され、移動が開始された状態を意味する。また、「検収」とは、得意先の検収が完了し、商品の所有権が得意先に移行した状態を意味する。また、「売上」とは、得意先の検収を確認し、得意先に対する債権金額が確定（＝債権を計上）した状態を意味する。

また、「検収」の用語は、「納入品やサービスが、注文通りの仕様（＝注文通りの数量、色や形、品質）になっているかを検査する業務」や「検収完了時、資産の所有権が移行する」という意味でも用いられる。なお、財務会計上（または、制度会計上）やＥＲＰシステム上では、資産の所有権の移行タイミングを明確にするために、「検収」というイベントが出庫と区別して定義される。

また、本例においては、プロセスフローＤＢ２２０には、プロセスフローデータ（または、プロセスフローテーブルＰＴ）の更新条件を示す更新条件データが登録される更新条件テーブルＵＴが備えられる。

図３は、プロセスフローＤＢ２２０における更新条件データの格納状態の例を示す説明図である。図３に示すように、本例における更新条件データは、業務プロセスの名称と、プロセスフローのタイプと、プロセスフローデータ更新条件とを含む。

ここで、「プロセスフローデータ更新条件」とは、プロセスフローのタイプに応じたプロセスデータの登録条件を示すものである。本例においては、プロセスフローデータ更新条件は、ある業務プロセスに関するプロセスデータをプロセスフローデータに追加する場合に、その前提としてプロセスフローデータが有しているべきプロセスデータの種類（すなわち、プロセスフローにおいて完了しているべき業務プロセスの種類）を示す。すなわち、更新条件テーブルＵＴが図３に示したものである場合、例えば業務プロセス「出庫検収」に関するプロセスデータがタイプ「在庫売上」のプロセスフローデータに追加されるには、予め定められた業務プロセス「受注」、「出荷指示」、および「出庫」（すなわち、図３において業務プロセス名称「出庫検収」とタイプ「在庫売上」と同一列のセルに「１」が設定された業務プロセス）に関するプロセスデータがプロセスフローデータに登録されている必要がある。なお、更新条件テーブルＵＴは、統合基幹業務システム５００の管理者によって作成される構成としてもよいし、クライアント１０，２０のユーザにより作成可能な構成とされていてもよい。

基幹業務サーバ２００は、プロセスフローＤＢ２２０およびその他ＤＢ２３０に格納された各種データを、所定の抽出条件に応じてＣＳＶ
（Comma Separated Values）形式に変換してＤＷＨサーバ３００に送信する機能を有する。なお、本例においては、基幹業務サーバ２００は、ＦＴＰ（File Transfer Protocol）によりＣＳＶ形式にしたデータファイルをＤＷＨサーバ３００に転送する。

ＤＷＨサーバ３００は、例えば本システムのシステム管理者によって管理されるサーバであり、データウェアハウスを実現するための各種の機能を有する。ここで、「データウェアハウス」とは、時系列で蓄積された帳票データなどの業務データ（本例においては、プロセスフローデータ）の中から各項目間の関連性を分析するシステムをいう。また、ＤＷＨサーバ３００は、基幹業務サーバ２００から転送されたＣＳＶ形式のファイルを所定のデータ形式に変換するなどして、所定の格納領域に各種データを登録する機能を有する。なお、ＤＷＨサーバ３００は、データ形式の変換を行わず、ＣＳＶ形式の状態から各格納領域に応じたデータを抽出する構成とされていてもよい。

クライアント１０，２０は、ＣＰＵ（中央処理装置）、ＲＯＭ、ＲＡＭ、および表示部などを備えた情報処理装置（クライアント端末）である。本例においては、クライアント１０，２０は、Ｗｅｂブラウザや表計算ソフトなど、帳票データを扱うために利用可能な各種アプリケーションを有しているものとする。また、本例においては、クライアント１０，２０は、例えばユーザによる操作入力に応じて、ＤＷＨサーバ３００から必要な帳票データ（本例においては、プロセスフローデータ）を取得するためのクエリ（検索項目、検索キー、抽出キーなど）を定義し、ＤＷＨサーバ３００に送信する機能を有する。

本例においては、クライアント１０は、ＬＡＮを介してＤＷＨサーバ３００と通信し、ＤＷＨサーバ３００から取得したデータを所定の表計算ソフトによって表示部に出力する機能を有する。

また、クライアント２０は、インターネットを介してＤＷＨサーバ３００と通信し、ＤＷＨサーバ３００から取得したデータをＷｅｂブラウザによって表示部に出力する機能を有する。

なお、本例においては、クライアント１０，２０は、基幹業務サーバ２００のプロセスフローＤＢ２２０に記憶されるプロセスフローデータに基づいて、所定の形態を有する帳票を自己が備える表示部に出力する機能を有する。

なお、統合基幹業務システム５００の構成はこれに限定されず、例えば、クライアント１０，２０と基幹業務サーバ２００とが、ＤＷＨサーバ３００を介さずに直接データの送受信を行える構成とされていてもよい。すなわち、クライアント１０，２０が、プロセスフローＤＢ２２０Ｂに直接アクセス可能な構成とされていてもよい。

次に、統合基幹業務システム５００における基幹業務サーバ２００の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。

図４は、基幹業務サーバ２００が実行するデータベース更新処理の例を示すフローチャートである。データベース更新処理では、基幹業務サーバ２００にてプロセスフローＤＢ２２０に記憶されたプロセスフローデータを更新するための処理が実行される。なお、本例においては、基幹業務サーバ２００は、業務アプリケーションプログラムＤＢ２１０に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータやプロセスフローデータを所定の時機に取得するものとする。

データベース更新処理において、先ず、基幹業務サーバ２００は、新たなプロセスフローデータ（新規プロセスフローデータ）を取得したか否かを判定する（ステップＳ１０１）。ここで、新規プロセスフローデータを取得していないと判定すると（ステップＳ１０１のＮ）、基幹業務サーバ２００は、後述するステップＳ１０３の処理に移行する。

一方、新規プロセスフローデータを取得したと判定すると（ステップＳ１０１のＹ）、基幹業務サーバ２００は、取得したプロセスフローデータをプロセスフローテーブルＰＴに登録する（ステップＳ１０２）。

次いで、基幹業務サーバ２００は、登録済みのプロセスフローデータに対応するプロセスデータ（すなわち、プロセスフローを構成する業務プロセスに関するデータ）を取得したか否かを判定する（ステップＳ１０３）。

なお、基幹業務サーバ２００による取得したプロセスデータが登録済みのプロセスデータである否かの判定は、取得したデータが有するプロセスフロー番号とプロセスフロー明細番号との組み合わせを有するプロセスフローデータがプロセスフローテーブルＰＴに格納されているか否かを判定することにより行う。そのため、本例においては、基幹業務サーバが取得するデータ（業務の実行者により入力されたデータ、または業務アプリケーションプログラムにより作成されたデータ）に、主キー部を構成するデータ（すなわち、プロセスフロー番号とプロセスフロー明細番号）が含まれることが必要となる。

ここで、登録済みのプロセスフローデータに対応するプロセスデータを取得していないと判定すると（ステップＳ１０３のＮ）、基幹業務サーバ２００は、その他ＤＢ２３０を参照し、取得したデータに対応する記憶領域を特定して、取得したデータを登録し（ステップＳ１０４）、ステップＳ１０１の処理に移行する。

一方、登録済みのプロセスフローデータに対応するプロセスデータを取得したと判定すると（ステップＳ１０３のＹ）、基幹業務サーバ２００は、取得したプロセスデータに対応する更新条件テーブルＵＴを参照して、取得したプロセスデータに応じた更新条件データを特定する（ステップＳ１０５）。本例においては、基幹業務サーバ２００は、プロセスデータが示す業務プロセスの種類とプロセスフローの識別情報（すなわち、プロセスフロー番号とプロセスフロー明細番号）に基づいて更新条件データを特定する。

更新条件データを特定すると、基幹業務サーバ２００は、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしているか否か判定する（ステップＳ１０６）。すなわち、基幹業務サーバ２００は、プロセスフローデータと更新条件データとに基づいて、取得したプロセスデータをプロセスフローデータの一部としてプロセスフローテーブルＰＴに登録するか否か判定する。本例においては、基幹業務サーバ２００は、取得したプロセスデータに対応するプロセスフローデータのステータス部と更新条件データとを比較し、更新条件データにて「１」が設定された業務プロセスがステータス部においても全て「１」に設定されている場合に、プロセスフローデータが更新条件を満たしていると判定する。

ここで、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていないと判定すると（ステップＳ１０６のＮ）、基幹業務サーバ２００は、所定のエラー処理を実行し（ステップＳ１０７）、ステップＳ１０１の処理に移行する。なお、「エラー処理」とは、プロセスフローデータを更新しない処理であれば特に限定されず、例えば、更新条件が満たされるまでプロセスデータを所定の記憶領域に一時的に保存する処理であってもよいし、更新条件を満たしていないプロセスデータを取得することとなった原因を調べるための処理（すなわち、エラーを管理者に報知する処理や、充足されていない更新条件の内容を管理者に報知する処理など）などであってもよい。

一方、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていると判定すると（ステップＳ１０６のＹ）、基幹業務サーバ２００は、プロセスフローテーブルＰＴに登録されたプロセスフローデータを更新する（すなわち、取得したプロセスデータをプロセスフローテーブルＰＴに登録する）（ステップＳ１０８）。

プロセスフローデータを更新すると、基幹業務サーバ２００は、プロセスフローデータの更新によりプロセスフローデータに関する所定のステータス変更条件が満たされたか否かを判定する（ステップＳ１０９）。ここで、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされていないと判定すると（ステップＳ１０９のＮ）、基幹業務サーバ２００は、ステップＳ１０１に移行する。

一方、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされたと判定すると（ステップＳ１０９のＹ）、基幹業務サーバ２００は、満たされたステータス変更条件に基づいて、プロセスフローデータが含むステータスデータを更新し（ステップＳ１１０）、ステップＳ１０１の処理に移行する。

本例におけるデータベース更新処理は、例えば、基幹業務サーバ２００の管理者による終了操作により終了する。

また、データベース更新処理は、リアルタイムに実行される処理であってもよいし、特定の単位時間毎に実行されるバッチ処理であってもよい。また、例えば指定された期間だけリアルタイム処理を行うような、一部にリアルタイム性を有した処理（準リアルタイム処理）であってもよい。

次に、本例の統合基幹業務システム５００における基幹業務サーバ２００とＤＷＨサーバ３００とクライアント１０，２０の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。

図５は、基幹業務サーバ２００と、ＤＷＨサーバ３００と、クライアント１０とが実行する帳票出力処理の例を示すフローチャートである。帳票出力処理では、基幹業務サーバ２００が、ＤＷＨサーバ３００を介してクライアント１０に対しプロセスフローデータ（プロセスフローデータの一部または全部）を提供することにより、クライアント１０が備える表示画面に帳票を表示するための処理が実行される。なお、クライアント１０とクライアント２０では、通信ネットワークの種類が異なるだけなので、本例においてはクライアント１０を用いる場合を例に説明を行なう。また、本例におけるＤＷＨサーバ３００は、基幹業務サーバ２００とクライアント１０とが通信を行うための補助（例えば、クライアントの認証など）を行うだけなので、以下ＤＷＨサーバ３００の動作についての説明は省略する。

また、本例においては、クライアント１０からの要求に応じて、基幹業務サーバ２００がプロセスフローデータを更新する場合についての説明も行う。なお、本例においては、ここで説明するプロセスフローＤＢ２２０の更新処理（すなわち、帳票出力処理におけるプロセスフローＤＢ２２０の更新処理）は、データベース更新処理（図４参照）の１例である。

帳票出力処理において、先ず、クライアント１０は、例えばクライアント１０のユーザＡによる操作入力に応じて、プロセスフローデータ更新要求入力画面要求を基幹業務サーバ２００に送信する（ステップＳ３０１）。

プロセスフローデータ更新要求入力画面要求を受信すると、基幹業務サーバ２００は、受信したプロセスフローデータ更新要求入力画面要求に応じたプロセスフローデータ更新要求入力画面を送信する（ステップＳ２０１）。

プロセスフローデータ更新要求入力画面を受信すると、クライアント１０は、自己が備える表示部の表示画面にプロセスフローデータ更新要求入力画面を表示する（ステップＳ３０２）。

図６は、プロセスフローデータ更新要求入力画面の例を示す説明図である。図６に示すように、プロセスフローデータ更新要求入力画面には、更新対象の識別情報（本例においては、プロセスフローデータの主キー部に対応するデータ。すなわち、プロセスフロー番号とプロセスフロー明細番号。）の入力を受け付ける主キーデータ入力領域１１と、ユーザＡによるプロセスデータが示す業務プロセスの種類の入力を受け付ける業務プロセス入力領域１２と、その他のプロセスデータの内容の入力を受け付ける詳細データ入力領域１３と、表示部に出力される表示画面を他の表示画面に切替える要求を受け付ける戻るボタン１４と、各入力領域（本例においては、主キーデータ入力領域１１、業務プロセス入力領域１２、詳細データ入力領域１３。）に入力された内容に基づくプロセスフローデータの更新要求を受け付ける更新ボタン１５とが設けられる。

クライアント１０は、例えばマウス操作により操作可能なカーソルＰによる各入力領域のうち何れかの選択を受け付けると、選択を受け付けた入力領域に対するテキストデータ（数字と文字とを含む。）の入力の受付を開始する。そして、例えばキーボードによるテキストデータの入力を受け付けると、クライアント１０は、受け付けたテキストデータを選択された領域に表示する。また、クライアント１０は、業務プロセス入力領域１２の選択を受け付けると、プルダウン形式で、所定の業務プロセス名称を選択可能に表示する。なお、プロセスデータの入力を受け付ける方法はこれに限定されず、例えば、クライアント１０が、所定のデータ形式にまとめられた複数のプロセスデータを１度に受け付ける構成としてもよい。

クライアント１０は、例えばマウス操作により更新ボタン１５の選択を受け付けると、各入力領域に入力されたデータにより構成されるプロセスデータによるプロセスフローデータの更新要求を受け付けたものと判定する（ステップＳ３０３）。

プロセスフローデータの更新要求（更新要求）を受け付けたものと判定すると、クライアント１０は、受け付けた更新要求を基幹業務サーバ２００に送信する（ステップＳ３０４）。

更新要求を受信すると、基幹業務サーバ２００は、プロセスフローテーブルＰＴに登録されたプロセスフローデータのうち、受信した更新要求に応じたプロセスフローデータを取得する（ステップＳ２０２）。なお、このとき基幹業務サーバ２００は、更新要求が示す主キーデータ（すなわち、主キーデータ入力領域１１に入力されたデータ）を含むプロセスフローデータを、更新要求（すなわち、受信したプロセスデータ）に応じたプロセスフローデータとして取得する。また、ここでの「取得」とは、後述する処理においてプロセスフローデータと更新条件データとを比較等するために一時的に所定の記憶領域に記憶するという意味である。

更新要求に応じたプロセスフローデータを取得すると、基幹業務サーバ２００は、更新要求に応じた更新条件データを取得する（ステップＳ２０３）。ここで、更新要求に応じた更新条件データとは、更新要求が示す業務プロセスとプロセスフローデータのタイプ（すなわち、業務プロセス入力領域１２に入力された業務プロセスと、ステップＳ２０２の処理にて取得したプロセスフローデータが示すタイプ）とにより特定可能な更新条件データを意味する（図３参照）。

更新条件データを取得すると、基幹業務サーバ２００は、取得したプロセスフローデータと更新条件データとを比較し（ステップＳ２０４）、プロセスフローデータの更新条件が満たされているか否か判定する（ステップＳ２０５）。

ここで、更新条件データにおいて「１」が設定された項目の何れか１つ以上がプロセスフローデータのステータス部において「１」に設定されていないことにより、プロセスフローデータの更新条件が満たされていないと判定すると（ステップＳ２０５のＮ）、基幹業務サーバ２００は、更新エラー通知を作成してクライアント１０に送信し（ステップＳ２０６）、ここでの処理を終了する。

更新エラー通知を受信すると（ステップＳ３０５のＹ）、クライアント１０は、受信した更新エラー通知に基づいて、自己が備える表示部の表示画面に更新エラー通知表示画面を表示する（ステップＳ３０６）。

図７は、更新エラー通知表示画面の例を示す説明図である。図７に示すように、更新エラー通知表示画面には、プロセスフローデータ更新要求入力画面に重畳して表示される更新エラー通知表示領域２１が設けられる。ここで、本例における更新エラー通知表示領域２１には、更新エラーをユーザＡに報知するための定型文の他、更新条件の詳細を表示する旨の要求を受け付けるための詳細表示ボタン２２と、更新エラー通知表示領域２１を表示画面から消去する旨の要求を受け付ける閉じるボタン２３とが設けられる。

クライアント１０は、ユーザＡによる詳細表示ボタン２２の選択を受け付けたことに応じて、例えば、基幹業務サーバ２００におけるプロセスフローデータと更新条件データとの比較結果をユーザＡが認識可能な形態（例えば、プロセスフローデータのステータス部と更新条件データのプロセスフローデータ更新条件とを示す対照表。）で表示する。

一方、更新条件データにおいて「１」が設定された項目の全てが、プロセスフローデータのステータス部において「１」に設定されていることによりプロセスフローデータの更新条件が満たされていると判定すると（ステップＳ２０５のＹ）、基幹業務サーバ２００は、更新要求が示すプロセスデータをプロセスフローデータに追加してプロセスフローデータを更新する（ステップＳ２０７）。

プロセスフローデータを更新すると、基幹業務サーバ２００は、更新したプロセスフローデータをクライアント１０に送信して（ステップＳ２０８）、ここでの処理を終了する。

一方、プロセスフローデータを受信すると、クライアント１０は、受信したプロセスフローデータに基づいて、自己が備える表示部の表示画面に帳票表示画面を表示する（ステップＳ３０７）。

図８は、帳票表示画面の例を示す説明図である。図８に示すように、帳票表示画面には、プロセスフローデータに基づいた帳票を表示する帳票表示領域３１と、帳票ステータス表示領域３２と、戻るボタン３３と、変更ボタン３４とが設けられる。なお、クライアント１０は、例えばクライアント１０に備えられたキーボードなどの操作に応じて帳票表示領域３１に表示される帳票の縮尺を変更する。

ここで、帳票表示領域３１には、所定の表示形態でプロセスフローデータの一部または全部が表示される。なお、本例においては、所定の表示形態でプロセスフローデータの一部または全部を表示するための情報が、基幹業務サーバ２００により作成されて、例えば帳票出力処理におけるステップＳ２０８のタイミングで、クライアント１０に送信されるものとする。なお、クライアント１０が、自己が備える記憶装置に記憶された情報に基づいて、受信したプロセスフローデータの一部または全部を所定の表示形態で帳票表示領域３１に表示する構成としてもよい。

また、帳票ステータス表示領域３２は、帳票表示領域３１に表示される帳票の種類（または、状況。以下、ステータスという。）を表示する領域である。なお、帳票のステータスとしては、例えば、受注伝票、出庫伝票、検収伝票、および請求書など、種々のものが考えられる。

また、戻るボタン３３は、表示画面をプロセスフローデータ更新要求入力画面に戻す旨の要求を受け付けるためのボタンである。なお、クライアント１０が、ユーザＡによる戻るボタン３３の選択を受け付けたことに応じて、表示画面をプロセスフローデータ更新要求入力画面に戻すだけでなく、基幹業務サーバ２００に対して、更新要求に基づくプロセスフローデータの更新を取り消す旨の要求を送信する構成としてもよい。この場合、クライアント１０は、戻すボタン３３の選択に応じて、各入力領域（本例においては、主キーデータ入力領域１１、業務プロセス入力領域１２、詳細データ入力領域１３。）に入力されていたテキストデータ（業務プロセス入力領域１２においては、選択されていた業務プロセス）を示す状態でプロセスフローデータ更新要求入力画面を表示する構成とされていてもよい。このような構成とすることにより、ユーザＡによる入力内容の確認を容易にすることができるようになる。

また、変更ボタン３４は、帳票表示領域３１の表示内容を変更する旨の要求を受け付けるためのボタンである。以下、帳票表示領域３１の表示内容の変更処理に関して説明する。

帳票表示画面を表示すると、クライアント１０は、ユーザＡによる帳票ステータス変更要求を受け付けたか否かを判定する（ステップＳ３０８）。

本例においては、クライアント１０は、先ず、ユーザＡによる帳票ステータス表示領域３２の選択を受け付ける。そして、例えばマウス操作により操作可能なカーソルＰによる帳票ステータス表示領域３２の選択を受け付けると、クライアント１０は、表示可能な帳票の形態を示す帳票ステータス名称のリストを、例えばプルダウン形式で選択可能に表示する。

なお、ここで表示する帳票ステータス名称については、基幹業務サーバ２００からプロセスフローデータと共に受信しているものとする。具体的には、基幹業務サーバ２００は、予め所定の記憶領域に記憶された帳票の形態に関するデータ（帳票形態データ）とプロセスフローデータの状態（すなわち、プロセスフローテーブルＰＴの各列項目の入力状態）とに基づいて、表示可能な帳票の形態を示す帳票ステータス名称を特定する。すなわち、例えばクライアント１０に送信するプロセスフローデータのタイプが「在庫売上」であり、プロセス固有データ部に業務プロセス「受注」に関するプロセスデータしか登録されていない場合には、基幹業務サーバ２００は、帳票ステータス名称として「受注伝票」のみを特定する。また、業務プロセス「受注」に関するプロセスデータの他、業務プロセス「出庫」に関するプロセスデータが登録されている場合、基幹業務サーバ２００は、帳票ステータス名称として、「受注伝票」と「出庫伝票」とを特定する。

図９は、プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。図９において、画像１０１〜１０４が、それぞれプロセスフローデータに基づいて帳票表示領域３１に表示され得る帳票（具体的には、伝票）の形態であるとする。なお、画像１０１〜１０４は、帳票ステータスの遷移について説明するための説明図であり、各種帳票としての役割を果たすための具体的記載例を示すものではない。

ここで、画像１０４を例にして説明すると、画像１０４における領域１１１が帳票ステータス名称を、領域１１２がプロセスフローのタイプを、領域１１３がプロセスフローデータに含まれるプロセスデータの業務プロセスの名称をそれぞれ示す領域（本例においては、文字列表示領域）であるものとする。なお、本例においては、プロセスフローデータに含まれるプロセスデータの種類に対応した帳票ステータス名称を領域１１１に表示している。

この場合、図９における画像１０１から画像１０４への遷移が示すように、１つのプロセスフローデータに対して各業務プロセスに応じたプロセスデータが登録されていく度に、帳票ステータス名称（すなわち、プロセスフローデータに基づいて表示可能な帳票の形態）の種類が増えていくことになる。これは、「次の種類の帳票があるかないか」ではなく、「プロセスフローデータの状態に応じて帳票のステータスが上がっていく（すなわち、表示可能な帳票の種類が増えていく）」ことを意味する。

以下、帳票出力処理におけるステップＳ３０７の処理の前に、クライアント１０が、業務プロセス「受注」，「出荷指示」，「出庫」，「出庫検収」を含むプロセスフローデータを受信した場合を例にして説明を続ける。なお、本例においては、ステップＳ３０７の処理にて、クライアント１０が、受信したプロセスフローデータが示すプロセスフローにおいて業務プロセス「受注」，「出荷指示」，「出庫」，「出庫検収」のうち最も上位に位置する業務プロセス「受注」に対応する帳票ステータス名称「受注伝票」に対応する帳票を、帳票表示領域３１に表示していたものとする（図８参照）。なお、クライアント１０は、ステップＳ２０７の処理にて新たにプロセスフローデータに追加されたプロセスデータに応じた業務プロセスに対応する帳票を帳票表示領域３１に表示する構成とされていてもよい。

帳票ステータス変更要求の受付判定処理（ステップＳ３０８）において、ユーザＡによる帳票ステータス変更要求を受け付けていないと判定すると（ステップＳ３０８のＮ）、クライアント１０は、後述するステップＳ３１０の処理に移行する。

一方、ユーザＡによる帳票ステータス変更要求を受け付けたと判定すると（ステップＳ３０８のＹ）、クライアント１０は、帳票表示領域３１に、受け付けた変更要求に応じた帳票を表示する（ステップＳ３０９）。本例においては、クライアント１０が、ユーザＡによる業務プロセス「出庫」に対応する帳票ステータス名称「出庫伝票」の選択を受け付けて、業務プロセス「出庫」に対応する帳票（出庫伝票）を帳票表示領域３１に表示するものとする。なお、この場合、クライアント１０は、帳票ステータス表示領域３２に、帳票ステータス名称「出庫伝票」を表示する。

帳票ステータス変更要求に応じた帳票を表示すると、クライアント１０は、帳票出力処理を終了するか否かを判定する（ステップＳ３１０）。ここで、帳票出力処理を終了しないと判定すると（ステップＳ３１０のＮ）、クライアント１０は、ステップＳ３０８の処理に移行する。

一方、例えばユーザＡによる所定の終了操作を受け付けたことにより帳票出力処理を終了するものと判定すると（ステップＳ３１０のＹ）、クライアント１０は、ここでの処理を終了する。

以上に説明したように、上述した実施の形態では、データベース（例えば、プロセスフローＤＢ２２０）が、複数の業務プロセスを含むプロセスフロー（例えば、タイプ「在庫売上」のプロセスフロー）に関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルＰＴと、プロセスフローデータの更新条件を示す更新条件データが登録される更新条件テーブルＵＴとを備え、プロセスフローデータが、ステータスデータと、共通データと、プロセス固有データとを含み、ステータスデータが、プロセスフローに含まれる複数の業務プロセス（例えば、受注、出荷指示、出庫、出庫検収、売上）それぞれの進捗状況を示すデータであり、共通データが、同一のプロセスフローに含まれる業務プロセス間で共通するデータ（例えば、受注先や金額などを示すデータ）であり、プロセス固有データが、同一のプロセスフローに含まれる各業務プロセスに固有のデータ（例えば、受注日や受注テキスト）であり、ステータスデータが、プロセス固有データが更新されたことに応じて更新され（例えば、プロセス固有データが追加されたことに応じて、対応するステータスデータが「０」から「１」に変更され）、更新条件データは、ステータスデータの状態を示すデータである構成としているので、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。

すなわち、データ更新時に発生するＩ／Ｏデータ（入出力データ）の量を少なくすることができるようになる。

図１０は、上述した基幹業務サーバ２００が実行するデータベース更新処理の有用性について説明するための説明図である。

図１０（Ａ）は、最初のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。ここで、最初に入力するプロセスデータの種類（すなわち、業務プロセスの種類）は特に限定されない。また、「従来型」とは、図１２に示したように、各業務プロセス毎にテーブルを備えたデータベースを意味する。また、「データ量の差」とは、厳密な数値を示すものではなく、従来型テーブルに格納されたデータを更新する場合と新規型プロセスフローテーブル（すなわち、プロセスフローテーブルＰＴ、図２参照。以下、従来型と比較する場合には適宜「新規型」と呼ぶ。）に格納されたデータを更新する場合とを比較した場合に、新規型の方が扱うデータ量が多くなる場合を＋（プラス）、新規型の方が扱うデータ量が少なくなる場合を−（マイナス）、新規型と従来型とで扱うデータ量が同じとみなせる場合を「０」とする。

この場合、最初のプロセスデータの入力時においては、ステータス部の更新が必要である分だけ新規型のほうが扱うデータ量が多くなる。ただし、ステータス部のデータ量は小さいので、実質的には従来型と新規型とで、Ｉ／Ｏデータ（入力データと出力データ）の量に大きな差はないといえる。

一方、図１０（Ｂ）は、２つ目のプロセス以降のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。すなわち、例えば、主キー部、参照キー部、タイプ部、ステータス部、共通データ部、およびプロセス固有データ部の一部（例えば、業務プロセス「受注」に応じたプロセス固有データ「受信日」，「受注テキスト」）がプロセスフローテーブルＰＴに入力済みのプロセスフローに含まれる業務プロセスに応じたプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。なお、「従来型」は、入力済みのプロセスデータとの対応関係を定義するために、例えば受注テーブルに登録されたプロセスデータ（受注データ）に対応する他のプロセスデータ（例えば、業務プロセス「出荷指示」に対応するプロセスデータ（出荷指示データ））を入力する場合には、出荷指示データとして、本例における主キー部、参照キー部、タイプ部、共通データ部、およびプロセス固有データ部に対応するデータ（図２と図１２参照）の他、対応する受注データを示す「受注番号」と「受注明細」とを入力する必要がある。

この場合、２つ目のプロセス以降のプロセスデータの入力時においては、ステータス部以外の全ての部分を必要とする従来型に比べて、新規型は、ステータス部とプロセス固有データ部のみを更新するので、Ｉ／Ｏデータの量が少なくなる。

よって、新規型の方が従来型よりもＩ／Ｏデータの量が少なくなり、システムのパフォーマンス上、有利となる。

すなわち、データベースのＩ／Ｏが削減することができるようになるため、書き込み量の減少、データベース全体の容量の縮減、およびデータの検索処理に要する処理負荷の軽減を実現することができるようになる。なお、検索処理に要する処理負荷の軽減に関しては、プロセス（プロセスデータ）が複数のテーブルにまたがっていないことも１つの要因となる。

また、新規型では、プレセスデータの入力順序をある程度、順不同にできるというメリットがある。すなわち、例えばタイプ「在庫売上」で考えると、従来型の場合、プロセスフローの順序が、受注、出荷指示、出庫、出庫検収、売上の順に限定され、順序を変えることができない。これは、従来型のテーブル構造では、業務プロセス間の関係を、後の業務プロセスのデータに前の業務プロセスの主キーを持たせることで表現しているためである（例えば、出荷指示テーブルにおける「受注番号」と「受注明細」。図１２参照）。一方、新規型のテーブル構造では、関係する業務プロセスのデータは、同一のエントリ（すなわち、同一テーブルの同一列）に格納される。このため、業務プロセス間の前後関係に制約を持たず、業務プロセスの順序を柔軟に組み替えることができるようになる。すなわち、例えば実際の業務の順序が「出荷指示の後に受注」であった場合に、プロセスデータの入力順序を、実際の業務の順序に沿った形にすることができるようになる。そのため、進捗管理上（言い換えれば、内部統制上）、従来型に対して有利である。なお、具体的には、現在の卸売業界の業務順序が「出荷指示の後に受注」である。

また、新規型では、更新条件データの内容を、例えばシステムの管理者やユーザにより設定可能な構成とすることにより、不正なプロセスデータの入力を防止することができるようになる。すなわち、更新条件データの設定によりプロセスデータの更新に制限を持たせることができるようになるため、例えば「出庫実績のない売上を計上できてしまう」など、内部統制上で問題のある順序に制限を設けることができるようになり、データベースに対する信頼性を向上させることができるようになる。

また、新規型では、プロセスフローの進捗の照会に要する負荷を軽減させることができるようになる。すなわち、プロセスフローがどこまで進んでいるか確認する場合、従来型のテーブル構造では、開始伝票のテーブルから順に、最終伝票のテーブルまでのすべてのテーブルの登録状況を確認する必要がある。例えば、タイプ「在庫売上」を例に考えると、受注、出荷指示、出庫、出庫検収、請求の５つのテーブルを確認する必要がある。一方、新規型のテーブル構造では、プロセスフローの進捗状況を「ステータス部」として持っているため、１つのテーブル、１つのエントリを照会するだけで進捗の確認ができるようになる。これは、進捗状況の照会画面を使用もしくは開発する際に、有利である。

また、上述した実施の形態では、データベース（例えば、プロセスフローＤＢ２２０）が、プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバ（例えば、基幹業務サーバ２００）に備えられ、プロセスフローデータ管理サーバが、クライアント端末（例えば、クライアント１０，２０）からの要求に応じて、プロセスフローデータの一部又は全部をクライアント端末に提供する構成としているので、業務フローに関するデータ（例えば、帳票の作成に必要な帳票情報を示すプロセスフローデータ）の提供に要する処理負荷が従来に比べて軽減されたシステムを構築することができるようになる。

また、上述した実施の形態では、プロセスフローデータ管理サーバ（例えば、基幹業務管理サーバ２００）が、複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付け、更新条件データに基づいて、受け付けたプロセスデータ（例えば、プロセスフローデータの更新要求が示すプロセスデータ）をプロセスフローデータの一部として登録するか判定し（例えば、プロセスフローデータが更新条件を満たしているか否かの判定。図４のステップＳ１０６、図５のステップＳ２０５参照。）、プロセスデータを登録するものと判定したことに応じて、プロセスフローテーブルＰＴに登録されたプロセスフローデータを更新する構成としているので、不正なデータの登録を防止することができるようになる。すなわち、例えばデータ管理の都合上、業務プロセスの一種である「出庫検収」を必ず業務プロセス「受注」、「出荷指示」、「出庫」に関するデータが登録された後にしか登録できないようにすることをユーザが望む場合に、更新条件データを設定するだけで、ユーザが望むようにプロセスフローデータの更新を制限することができるようになる。

なお、上述した実施の形態では特に言及していないが、プロセスフローデータ管理サーバ（例えば、基幹業務サーバ２００）が、プロセスデータを登録しないと判定したことに応じて、満たされていない更新条件である非充足更新条件を特定し、特定した非充足更新条件をクライアント端末（例えば、クライアント１０，２０）に報知し、所定のタイミングで、非充足更新条件として特定した更新条件が満たされたか判定し、非充足更新条件として特定された更新条件が満たされたと判定したことに応じて、更新条件に対応するプロセスデータをプロセスフローテーブルＰＴに登録する構成としてもよい。

このような構成とすることにより、クライアント端末のユーザが、同じデータを複数回入力しなければならないということを防止することができるようになる。すなわち、非充足更新条件を報知されたユーザは、非充足条件を満たすための操作を行えば既に入力済みのプロセスデータがプロセスフローテーブルに登録されることとなるので、改めてプロセスフローデータを入力する必要がなくなる。また、プロセスフローデータ管理サーバにとっては、受け付けたプロセスデータに対応するプロセスフローデータの特定や更新条件の充足判定に必要な処理を再度行わずにすむこととなるため、同一処理の実行回数を減らすことができるようになる。

なお、上述した実施の形態では特に言及していないが、データベース（例えば、プロセスフローＤＢ２２０）が、プロセスフローの進捗状況の判定条件を示すデータである進捗状況判定条件データが登録された進捗状況判定条件テーブルを備え、プロセスフローデータ管理サーバ（例えば、基幹業務サーバ２００）が、進捗状況判定条件に基づいてステータスデータ（例えば、プロセスフローテーブルＰＴにおけるステータス部に格納されたデータ。図２参照。）が進捗状況判定条件を満たしているか判定し、満たしていると判定した進捗状況判定条件に応じた進捗状況をクライアント端末（例えば、クライアント１０，２０）に報知する構成としてもよい。

図１１は、進捗状況判定条件テーブルに格納された進捗状況判定条件データの格納状態の例を示す説明図である。図１１に示すように、本例における進捗状況判定条件データは、プロセスフローのタイプと、プロセスフローのタイプに応じた進捗状況判定条件とを含む。

ここで、プロセスフローのタイプには、上述した在庫売上の他、サンプル出荷、サービス売上、名義変更（売上）、名義変更（出荷）、売上返品（元取引参照あり）、売上返品（元取引参照なし）、売上金額調整（プラス）、売上金額調整（マイナス）など、業務プロセスの異なる種々のものが考えられる。

また、「進捗状況判定条件」とは、プロセスフローの進捗状況の判定基準を示すものであり、本例においては、プロセスフローのタイプ毎に必要な業務プロセス（例えば、受注、出荷指示、出庫、出庫検収、および売上のうち予めタイプ別に設定された業務プロセス）に「１」が設定されているものとする。

基幹業務サーバ２００は、プロセスフローテーブルＰＴに格納されたプロセスフローデータのうち、ステータス部の状態が進捗状況判定条件データと一致した場合に、プロセスフローデータのエントリが「完了」の状態にあると判定し（すなわち、プロセスフローデータが示すプロセスフローが完了したと判定し）、その旨を所定のクライアント（例えば、クライアント１０，２０）に報知するための処理（報知処理）を行う。

このような構成とすることにより、業務遂行状況の判定が可能なシステムを構築することができるようになる。特に、プロセスフローデータが含むステータスデータと進捗状況判定条件データとを比較するだけで業務遂行状況の判定処理が可能となるため、複数のテーブルに格納されたデータの入力状況を参照する必要がある従来のものと比べて、業務遂行状況の判定に要する処理負荷を軽減させることができる。

なお、進捗状況の判定処理または報知処理の開始時機は、クライアント端末からの要求があったときであってもよいし、予め設定された時機であってもよい。

また、上述した進捗状況判定条件テーブルの例では、進捗状況判定条件データが、プロセスフローが完了したか判定するための完了条件を含む構成としているので、一連の業務の完了判定が容易に可能なシステムを構築することができるようになる。

なお、進捗状況判定条件データは、プロセスフローが「完了」の状態にあると判定するためのものに限定されず、例えば、「５０％完了」の状態にあると判定するためのデータが含まれる構成としてもよい。また、進捗状況判定条件データが、最初のプロセスデータの入力時から所定時間が経過するまでに入力されるべきであるプロセスデータの種類を示す構成としてもよい。

また、進捗状況判定条件テーブルに、上述したような「入力されるべきデータが全て入力されたか」の判定機能だけでなく、「入力されるべきではないデータが入力されないよう」にデータの入力を制限する機能を持たせる構成としてもよい。この場合、例えば、基幹業務サーバ２００が、プロセスフローテーブルＰＴを更新するときに、追加するプロセスデータがプロセス固有データである場合に、追加するプロセス固有データの種類と進捗状況判定条件テーブルとを比較して、追加するプロセス固有データの種類が進捗状況条件テーブルに「１」が設定されていない業務プロセスに対応するものである場合にはプロセスフローテーブルの更新をしない構成とすればよい。

なお、上述した実施の形態では特に言及していないが、データベース（例えば、プロセスフローＤＢ２２０）が、所定のデータが入力されたことに応じて、プロセスフローテーブルＰＴに登録済みのデータのうち少なくとも一部に、データ内容の変更に関する制限を設ける構成としてもよい。

すなわち、例えば、プロセスフローＤＢ２２０が備えるプロセスフローテーブルＰＴにプロセス「出庫検収」に関するプロセス固有データが登録される前では、プロセスフローテーブルＰＴにおける共通データ部の変更（例えば、データの削除や上書き）が可能であるが、プロセスフローテーブルＰＴにプロセス「出庫検収」に関するプロセス固有データが登録された後では、共通データ部の変更が自由にできないようになる構成としてもよい。この場合、例えば、ユーザが共通データ部の内容を変更する場合に入力すべきパスワードや満たすべき条件などの制限を加える構成とすればよい。このような構成とすることにより、一部のデータの変更に伴うデータ全体における矛盾の発生（すなわち、入力済みのデータの修正に伴う関連データの整合性の欠落）を防止することができるようになる。

本発明によれば、データの更新や検索に要する処理負荷を軽減させたＥＲＰシステムを構築するのに有用である。

ＰＴ プロセスフローテーブル
ＵＴ 更新条件テーブル
１０ クライアント
２０ クライアント
５１ 専用回線
５２ ＬＡＮ
５３ インターネット
２００ 基幹業務サーバ
２１０ 業務アプリケーションプログラムＤＢ
２２０ プロセスフローＤＢ
２３０ その他ＤＢ
３００ ＤＷＨサーバ
５００ 統合基幹業務システム

Claims (4)

1. クライアント端末に対して各種データを提供するデータ管理サーバに備えられ、当該データを格納するデータベースであって、
   前記データベースは、
   複数の業務プロセスを含むプロセスフロー毎に発生する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルと、
   前記プロセスフローデータの更新条件を示す更新条件データが登録される更新条件テーブルとを備え、
   前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、
   前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、
   前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、
   前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、
   前記ステータスデータは、前記プロセス固有データが更新されたことに応じて前記データ管理サーバにより更新され、
   前記更新条件データは、前記ステータスデータの状態を示すデータであり、
   前記データ管理サーバは、
   前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付手段と、
   前記更新条件データに基づいて、前記プロセスデータ受付手段により受け付けられたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定手段と、
   該登録判定手段により前記プロセスデータを登録するものと判定されたことに応じて、前記プロセスフローテーブルに登録されたプロセスフローデータを更新するプロセスフローデータ更新手段と、
   前記登録判定手段により前記プロセスデータを登録しないと判定されたことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定手段と、
   該非充足更新条件特定手段により特定された非充足更新条件を前記クライアント端末に報知する報知手段と、
   所定のタイミングで、前記非充足更新条件として特定された更新条件が満たされたか判定する充足判定手段とを含み、
   前記プロセスフローデータ更新手段は、前記充足判定手段により前記非充足更新条件として特定された更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録する
   ことを特徴とするデータベース。
2. 前記データ管理サーバは、クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段を含む
   請求項１記載のデータベース。
3. クライアント端末に対して各種データを提供するデータ管理サーバであって、
   複数の業務プロセスを含むプロセスフロー毎に発生する各種データを含むプロセスフローデータと、該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段と、
   前記プロセスフローの進捗状況に応じて前記プロセスフローデータを更新するプロセスフローデータ更新手段と、
   前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段と、
   前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付手段と、
   前記更新条件データに基づいて、前記プロセスデータ受付手段により受け付けられたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定手段と、
   前記登録判定手段により前記プロセスデータを登録しないと判定されたことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定手段と、
   該非充足更新条件特定手段により特定された非充足更新条件を前記クライアント端末に報知する報知手段と、
   所定のタイミングで、前記非充足更新条件として特定された更新条件が満たされたか判定する充足判定手段とを含み、
   前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、
   前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、
   前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、
   前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、
   前記更新条件データは、前記ステータスデータの状態を示すデータであり、
   前記プロセスフローデータ更新手段は、
   前記登録判定手段により前記プロセスデータを登録するものと判定されたことに応じて、前記プロセスフローテーブルに登録されたプロセスフローデータを更新し、
   前記充足判定手段により前記非充足更新条件として特定された更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録する
   ことを特徴とするデータ管理サーバ。
4. クライアント端末に対して各種データを提供するようにデータ管理サーバに動作制御させるためのデータ管理プログラムであって、
   前記データ管理サーバに、
   複数の業務プロセスを含むプロセスフローの進捗状況に応じて前記プロセスフロー毎に発生する各種データを含むプロセスフローデータと該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理と、
   前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供処理と、
   前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付処理と、
   前記更新条件データに基づいて、前記プロセスデータ受付処理にて受け付けたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定処理と、
   前記登録判定処理にて前記プロセスデータを登録しないと判定したことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定処理と、
   該非充足更新条件特定処理にて特定した非充足更新条件を前記クライアント端末に報知する報知処理と、
   所定のタイミングで、前記非充足更新処理にて特定した更新条件が満たされたか判定する充足判定処理とを実行させ、
   前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、
   前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、
   前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、
   前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、
   前記更新条件データは、前記ステータスデータの状態を示すデータであり、
   前記プロセスフローデータ更新処理では、
   前記登録判定処理にて前記プロセスデータを登録するものと判定したことに応じて、前記プロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新する処理と、
   前記充足判定処理にて前記非充足更新条件として特定した更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録する処理とを
   実行させるためのデータ管理プログラム。

Images