JP2007293837A - 業務管理方法、並びに業務管理装置 - Google Patents

Abstract

【課題】どのような業種・業態や顧客ニーズであっても、あらゆる業務を一元的（統一的）に表すことにより、業務のシステム化を行う。
【解決手段】ある業務の実行に対応する数値情報を格納するＰｌｕｓサブフィールドと、前記業務の次工程業務の実行に対応する数値情報を格納するＭｉｎｕｓサブフィールドを有するレコードからなるテーブルを記憶するテーブル記憶部と、始点タイプの業務が実行された場合には、Ｐｌｕｓサブフィールドにのみ数値情報を格納したレコードである自身レコードを生成してテーブルに追加し、中間タイプの業務が実行された場合には、Ｍｉｎｕｓサブフィールドに数値情報を格納するレコードである前身レコードと、Ｐｌｕｓサブフィールドにのみ数値情報を格納するレコードである自身レコードとを生成してテーブルに追加する処理実行部とを有する。
【選択図】 図８

Description

本発明は、業務管理方法、並びに業務管理装置に関する。

企業活動において計算機を活用した業務設計／業務機械化を実施するためには、ユーザは個々の業務機能や構造を定義し、人が対応したり、運用するような業務内容・項目と計算機が処理する業務内容・項目などを整理し、設計する必要がある。通常、業務の構造を設計しようとすると、ユーザの業務構造を設計し、アプリケーションパッケージの持っている業務機能で実現しようとするとどうなるかを試行錯誤的に繰り返して設計している。さらにこれらを効率的にするための方法としては、アプリケーションパッケージは汎用的な側面を持つので、特定のユーザで設計されるような業務構造を持てないので個別のユーザでの設計構築事例を蓄積し、この事例を流用して作成する方法が取られている。

従って、アプリケーションパッケージを前提にした業務構造設計では、以下の問題点がある。（１）従来の方法でまず、ユーザの業務構造を設計し、パッケージの持っている業務機能で実現させるために試行錯誤的を繰り返して設計する方法では、設計工数が多大である。（２）また、事後の組織の改編や、業務内容の改革・変更などによりユーザの業務構造が変化した場合に、この変化に応じて業務アプリケーションを変更する場合には、各モジュールなどの変更ばかりでなく、データベース構造の変更を行う必要があり、時間と費用が多大に必要となっていた。

本発明の第１の目的は、どのような業種・業態や顧客ニーズであっても、あらゆる業務を一元的（統一的）に表すことにより、業務のシステム化を行う技術を提供することにある。

本発明の第２の目的は、どのような業種・業態や顧客ニーズであっても、あらゆる業務を一元的（統一的）に表すことにより、業務管理システムの開発工数を劇的に減少させ、開発にかかる時間及び費用を低減させる技術を提供することにある。

上記課題を解決するための手段として、本発明は以下の特徴を有している。

本発明の第１の態様は、第１の業務の実行に対応する数値情報を格納する第１のフィールド（例えば、消込サブフィールドにおけるＰｌｕｓサブフィールド）と、第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第２のフィールド（例えば、消込サブフィールドにおけるＭｉｎｕｓサブフィールド）を有するレコードからなるテーブル（例えば、業務フローテーブル）を用い、第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、第１の業務に応じた第２の業務が完了したことを判定することを特徴とする業務管理方法である。

かかる業務管理方法によれば、第１のフィールド、第２のフィールドに数値情報を格納することにより業務の記録をつけることができ、且つ第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより業務の完了を判定できるようになる。

本発明の第２の態様は、業務管理方法として提案される。

この業務管理方法は、ある業務の実行に対応する数値情報を格納する第１のフィールド（例えば、消込サブフィールドにおけるＰｌｕｓサブフィールド）と、業務の次工程として行われる業務の実行に対応する数値情報を格納する第２のフィールド（例えば、消込サブフィールドにおけるＭｉｎｕｓサブフィールド）を有するレコードからなるテーブル（例えば、業務フローテーブル）を用いる業務管理方法であって、始点タイプの業務が実行された場合には、第１のフィールドに数値情報を格納するが第２のフィールドには数値情報を格納しないレコードである自身レコードを生成してテーブルに追加するステップと、中間タイプの業務が実行された場合には、第１のフィールドに数値情報を格納せず第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、第１のフィールドに数値情報を格納するが、第２のフィールドには数値情報を格納していないレコードである自身レコードを生成してテーブルに追加するステップとを有することを特徴とする。

また、上記の業務管理方法において、終点タイプの業務が行われた場合には、第１のフィールドに数値情報を格納せず第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、第１のフィールドにも、第２のフィールドにも数値情報を格納していないレコードである自身レコードを生成してテーブルに追加するステップをさらに有するようにしてもよい。

また、上記業務管理方法は、第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、業務の完了を判定するステップをさらに有するものとしてもよい。

かかる業務管理方法によれば、第１のフィールドと、第２のフィールドが複式簿記の「貸方」「借方」と同様に機能し、業務の未完了、例えば、１０個の出荷指示が為されているのに、この指示に基づいて８個の出荷しか為されていないことが迅速且つ勘弁に発見することが可能となる。また、従前の業務管理方法においては、例えば業務毎にテーブル、記録ファイルを用いていたため、全体では膨大な数のテーブル、記録ファイル群が必要となっていたが、本業務管理方法では、複数の業務についても一のテーブルで管理するため、簡易且つ単純な方法で業務管理を行うことができる。

またさらに、上記業務管理方法において、テーブルは、業務フロー毎に設けられているようにしてもよい。かかる業務管理方法によれば、業務フロー毎のテーブルを用いるため、例えば、企業の組織変更や業務見直しなどにより業務フローの変更が生じた場合にも、個々の業務フローに応じた業務管理方法の修正で対応でき、業務管理方法全体のプログラム改修などを行う必要が無くなる。

また、レコードは未実行の業務であるか否かを区別するためのフィールドをさらに有するようにしてもよい。かかる業務管理方法によれば、将来の予測も可能な業務管理が可能となる。

またさらに、レコードは第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報に対応する金銭価値を格納するフィールドをさらに有するようにしてもよい。かかる業務管理方法によれば、財務・会計に関する情報を得ることが可能な業務管理が実現できる。

本発明の第３の態様は、業務管理装置（例えば、業務管理サーバ）として提案される。

この業務管理装置は、第１の業務の実行に対応する数値情報を格納する第１のフィールドと、第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第２のフィールドを有するレコードからなるテーブル（例えば、業務フローテーブル）を記憶し、第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、第１の業務に応じた第２の業務が完了したことを判定する、ことを特徴とする。

かかる業務管理装置によれば、第１のフィールド、第２のフィールドに数値情報を格納することにより業務の記録をつけることができ、且つ第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより業務の完了を判定できるようになる。

本発明の第４の態様は、ある業務の実行に対応する数値情報を格納する第１のフィールドと、業務の次工程として行われる業務の実行に対応する数値情報を格納する第２のフィールドを有するレコードからなるテーブル（例えば、業務フローテーブル）を用いて、業務を管理する業務管理装置として提案される。

この業務管理装置は、テーブルを記憶する記憶手段（例えば、テーブル記憶部）と、始点タイプの業務が実行された場合には、第１のフィールドに数値情報を格納するが第２のフィールドには数値情報を格納しないレコードである自身レコードを生成してテーブルに追加し、中間タイプの業務が実行された場合には、第１のフィールドに数値情報を格納せず第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、第１のフィールドに数値情報を格納するが、第２のフィールドには数値情報を格納していないレコードである自身レコードを生成してテーブルに追加する処理手段（例えば、処理実行部）とを有することを特徴とする。

上記装置において、処理手段は、終点タイプの業務が行われた場合には、第１のフィールドに数値情報を格納せず第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、第１のフィールドにも、第２のフィールドにも数値情報を格納していないレコードである自身レコードを生成してテーブルに追加するようにしてもよい。

また、上記装置において、処理手段は、第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、業務の完了を判定するようにしてもよい。

かかる業務管理装置によれば、第１のフィールドと、第２のフィールドが複式簿記の「貸方」「借方」と同様に機能し、業務の未完了、例えば、１０個の出荷指示が為されているのに、この指示に基づいて８個の出荷しか為されていないことが迅速且つ勘弁に発見することが可能となる。また、従前の業務管理装置においては、例えば業務毎にテーブル、記録ファイルを用いていたため、全体では膨大な数のテーブル、記録ファイル群が必要となっていたが、本業務管理装置では、複数の業務についても一のテーブルで管理するため、簡易且つ単純な方法で業務管理を行うことができる。

さらにまた、上記装置において、記憶手段は、業務フロー毎にテーブルを記憶しているようにしてもよい。かかる業務管理装置によれば、業務フロー毎のテーブルを用いるため、例えば、企業の組織変更や業務見直しなどにより業務フローの変更が生じた場合にも、個々の業務フローに応じた業務管理方法の修正で対応でき、業務管理方法全体のプログラム改修などを行う必要が無くなる。

またさらに、上記装置において、記憶手段に記憶されたテーブルにおいて、各レコードは未実行の業務であるか否かを区別するためのフィールドを有するようにしてもよい。かかる業務管理装置によれば、将来の予測も可能な業務管理が可能となる。

またさらに、上記装置において、レコードは第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報に対応する金銭価値を格納するフィールドをさらに有するようにしてもよい。かかる業務管理方法によれば、財務・会計に関する情報を得ることが可能な業務管理が実現できる。

本発明の第５の態様は、業務管理方法として提案される。この業務管理方法は、第１の業務の実行に対応する数値情報、又は前記第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第１のフィールド（例えば、フローコアテーブルに２３２３の「数量」フィールド）と、そのレコードが自身レコードか前身レコードかを識別する第２のフィールド（例えば、フローコアテーブルに２３２３の「行Ｎｏ．」フィールド）とを有するレコードを有するテーブル（例えば、フローコアテーブル）を用い、前記第１のフィールドに格納された数値情報を比較することにより、前記第１の業務に応じた第２の業務が完了したことを判定する、ことを特徴とする業務管理方法。

本発明の第６の態様は、第１の業務の実行に対応する数値情報、又は前記第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第１のフィールド（例えば、フローコアテーブルに２３２３の「数量」フィールド）と、そのレコードが自身レコードか前身レコードかを識別する第２のフィールド（例えば、フローコアテーブルに２３２３の「行Ｎｏ．」フィールド）とを有するレコードを有するテーブル（例えば、フローコアテーブル）を記憶し、前記第１のフィールドに格納された数値情報を比較することにより、前記第１の業務に応じた第２の業務が完了したことを判定する、ことを特徴とする業務管理装置として提案される。

本発明によれば、業務フローテーブルを用いることによりあらゆる業務を一元的（統一的）に表すことにより、業務のシステム化を行うことができ、また業務フローテーブルを用いることによりあらゆる業務を一元的（統一的）に表すことにより、業務管理システムの開発工数を劇的に減少させ、開発にかかる時間及び費用を低減させることができる。

以下、図面を参照しながら本発明の実施の形態を説明する。

［１．基本的考え方］
本実施の形態にかかる業務管理システムは、以下の考えに基づいて考案されている。

［１．１．業務について］
本発明においては、業務（企業などの活動全体ではなく、活動を構成する構成要素、例えば、受注、出荷、請求など）は、業務依頼者もしくは指示者（人、部、課、グループなど）と業務実行者（人、部、課、グループなど）との関係の間で遂行される。

よって「業務」であれば、かならず受払（ＴＲＡＤＥ）が発生する。「受払」とは、ある担当者が自分の担当する業務を行ったことを次工程の業務担当者に知らせる通知、報告、指示など（以下、通知と総称する）を次工程の担当者に送った場合に、次工程の担当者がこの通知に対応する行為を行うことをいう。すなわち、「受払」は、通知と消込によって構成される。例えば、「注文受注」という行為を業務と捉えた場合、「注文受注」を担当する業務実行者（注文受注担当者）は、「この注文受注を処理しました」、という通知を次工程の業務実行者（出荷担当者）に渡し、出荷担当者はこの注文受注に応じた出荷を実行する。通知に対応する次工程の業務の実行を「消込」と呼ぶ。

［１．２．消込］
この「消込」は、「数値化された情報」、例えば個数、数量、件数、進歩率、金額などによって行われる。なお、上記の数値化された情報のうち、「金額」は特殊な扱いとなる。「金額」は、人類が扱う「様々な物、サービス、その他の有価対象」と交換できる「共通の尺度」である。そのため、数値化された情報には、金額を併記するようにしてもよい。例えば、消込に用いる数値化された情報が個数（例えば、テレビの台数）である場合にその個数に応じた金額を、数値化された情報として扱うようにしてもよい。

［１．３．業務フロー］
業務は次工程の業務と受払によって連結される。受払によって連結された一繋がりの業務を「業務フロー」と呼ぶ。

［１．４．業務のタイプ］
本発明において、業務フローを構成する業務は３つのタイプに分類される。以下、図１を参照しながら説明する。
（１）始点タイプ
図１（Ａ）は、始点タイプの業務を示す図である。

始点タイプの業務１１は、業務フローの始点となる業務であって、前工程となる業務はなく、そのため前工程の業務との間での受払（通知と消込）は、存在しない。始点タイプの業務１１は、次工程となる業務に対して通知２１のみ行う。
（２）中間タイプ
図１（Ｂ）は、中間タイプの業務を示す図である。

中間タイプの業務１２は、前述の始点タイプの業務と、後述する終点タイプの業務との間に位置する業務であって、前工程となる業務からの通知に対応する消込２２を行うとともに、次工程となる業務に通知２３を行う。
（３）終点タイプ
図１（Ｃ）は、終点タイプの業務を示す図である。

終点タイプの業務１３は、業務フローの終点となる業務であって、次工程となる業務が存在しないため、前工程の業務からの通知に対応する消込２４のみ行う。

一つの業務フローは、始点タイプの業務１１、終点タイプの業務１３、及び必要な場合には１又は複数の中間タイプの業務１２を直列的に連結することにより構成される。

［１．５．業務フローの例］
次に、業務フローの例について説明する。図２は、始点タイプの業務１１、一つの中間タイプの業務１２、及び終点タイプの業務１３が直列的に連結されて構成された業務フローの概念図である。始点タイプの業務１１は、中間タイプの業務１２に対して通知２１を出し、中間タイプの業務１２は通知２１に対応する消込２２を行う。中間タイプの業務１２は、終点タイプの業務１３に対して通知２３を出し、終点タイプの業務１３は通知２３に対応する消込２４を行う。

［１．６．業務フローテーブル］
これら通知２１、消込２２、通知２３、消込２４は、共通のテーブルに記述或いは記録される。このテーブルを業務フローテーブルと呼ぶ。図３は、図２に示す業務フローに対応した業務フローテーブル２００の具体的構成例を示す図である。図３に示す業務フローテーブル２００は、レコード３０１（各レコードを区別するため、添え字Ａ〜Ｅを付す）を追加することが可能なデータである。レコード３０１は、いずれかの業務の通知或いは消し込みに対応している。

図３に示した例では、３つすべての業務１１〜１３が完了した時点の業務フローテーブルを示している。なお、本明細書中では説明の都合上便宜的に通知、消込に対応するレコードを記述又は記録するデータを「テーブル」と呼ぶが、本発明において通知、消込を記録するデータがテーブル構造を有することに限定される趣旨ではなく、通知、消込を互いに比較可能なデータ構造であればどのような構造のデータ形式、データ構造を用いても構わない。

さて、図３に示す例おいて、レコード３０１Ａは、業務１１の通知２１に対応して生成されたレコードであり、レコード３０１Ｂは、業務１２の消込２１に対応して生成されたレコードであり、レコード３０１Ｃは、業務１２の通知２３に対応して生成されたレコードであり、レコード３０１Ｄ、３０Ｅは、業務１３の消込２４に対応して生成されたレコードである。

各レコード３０１は、自身業務区別ナンバーフィールド３０２と、前身業務区別ナンバーフィールド３０３と、ターゲットフィールド３０４とを有している。ターゲットフィールド３０４は、計上サブフィールド３０５と、消込サブフィールド３０６とを有している。計上サブフィールド３０５と消込サブフィールド３０６とはそれぞれ、「Ｐｌｕｓ（プラス）」サブフィールド３０７，３１０と、「Ｍｉｎｕｓ（マイナス）」サブフィールド３０８、３１１と、「Ｕｎｉｔ（単位）」サブフィールド３０９，３１２とを有している。

自身業務区別ナンバーフィールド３０２は、そのレコードを生成させた業務（「自身業務」と呼ぶ）を一意に特定する情報、例えば、業務ＩＤナンバーを格納するフィールドである。このフィールドに格納された情報を参照することにより、そのレコードはどの業務の実行によって生成されたのか特定できる。

前身業務区別ナンバーフィールド３０３は、当該レコードに対応する自身業務の前工程である業務（「前身業務」と呼ぶ）を一意に特定する情報、例えば、業務ＩＤナンバーを格納するフィールドである。このフィールドに格納された情報を参照することにより、そのレコードにより消込を行う対象のレコードを特定できる。

計上サブフィールド３０５のＰｌｕｓサブフィールド３０７、Ｍｉｎｕｓサブフィールド３０８は、その業務において発生した、数値化された情報（以下、数値情報と呼ぶ）をユーザから特別の指示、指定がない限り正の値で格納する。

消込サブフィールド３０５のＰｌｕｓサブフィールド３１０、Ｍｉｎｕｓサブフィールド３１１は、通知及びこれに対応する消込において発生した数値情報を格納する。

Ｕｎｉｔサブフィールド３０９、３１２はそのレコードの数値情報が示している対象の単位（例えば、台数、個数、重量、など）を格納する。なお、同一の業務フローテーブル２００のレコード３０１相互では、Ｕｎｉｔサブフィールド３０９、３１２の内容が異なることもあり得る。

業務フローテーブル２００に格納されるレコードには、前身レコードと、自身レコードの２種類がある。図３では、レコード３０１Ｂ、３０１Ｄが前身レコードであって、レコード３０１Ａ、３０１Ｃ、３０１Ｅが自身レコードである。

前身レコードは、前述の「消込」に対応するレコードであって、Ｍｉｎｕｓサブフィールド３１１に数値情報が、ユーザが特別に指示、指定しない限り正の値で格納される。また、自身業務区別ナンバーフィールド３０２には、その「消込」を行う業務である自身業務を一意に特定する情報、例えば業務ＩＤナンバーなどが格納されるとともに、前身業務区別ナンバーフィールド３０３に、当該レコードの自身業務の前身業務を一意に特定する情報、例えば業務ＩＤナンバーなどが格納される。

自身レコードは、前述の「通知」に対応するレコードであって、Ｐｌｕｓサブフィールド３１０に数値情報が、ユーザに明示されない限り正の値で格納される。また、自身業務区別ナンバーフィールド３０２には、その「通知」を行う業務である自身業務を一意に特定する情報、例えば業務ＩＤナンバーなどが格納されるが、前身業務区別ナンバーフィールド３０３には前身業務を一意に特定する情報は格納されない。

この自身レコードと前身レコードの消込サブフィールド３０６のＰｌｕｓサブフィールド３１０及びＭｉｎｕｓサブフィールド３１１の両者の数値情報を対比することにより、業務フローに残がないこと、すなわち、仕事が完結していることがわかる。仮に両者の数値情報がバランスしていない、すなわち、一方が他方より多い場合には、この業務フローに含まれるどこかの業務に処理されていない残があることを意味する。言い換えれば、業務フローテーブル２００の消込サブフィールド３０６のＰｌｕｓサブフィールド３１０及びＭｉｎｕｓサブフィールド３１１に格納された数値情報を調べることにより、仕事が完結しているか否かを迅速且つ簡易に判断することができるようになっている。

また、自身業務区別ナンバーフィールド３０２と、前身業務区別ナンバーフィールド３０３とに格納される業務を特定する情報が一致する自身レコード及び前身レコードは対となる通知及び消込となる。すなわち、同じ業務を特定する情報を自身業務区別ナンバーフィールド３０２又は前身業務区別ナンバーフィールド３０３に格納するレコード３０１を業務フローテーブル２００から抽出し、抽出したレコード３０１すべての消込サブフィールド３０６のＰｌｕｓサブフィールド３１０及びＭｉｎｕｓサブフィールド３１１に格納された数値情報を調べることにより、各業務間での仕事の完了を迅速且つ簡易に調べることも可能である。

なお、業務フローテーブルには、消込がされていない対象の数である「残」を格納するフィールドを設ける必要はない。なぜなら、「残」のフィールドが既存のあらゆる情報システムの問題の重要な一因であるためである。

［１．７．業務のタイプと自身レコード、前身レコード］
先に、業務には、始点タイプ、中間タイプ、終点タイプの３種類があることを述べたが、業務フローテーブルに記述される自身レコード、前身レコードは、これら業務のタイプ別に異なった扱いがなされる。

（１）始点タイプ
始点タイプの業務、より詳しくは始点タイプの業務の通知２１について、自身レコードは作成されるが、前身レコードは作成されない。始点タイプの業務の通知２１に応じて作成される自身レコードにおいては、この自身レコードの計上サブフィールド３０５のＰｌｕｓサブフィールド３０７、及び消込サブフィールド３０６のＰｌｕｓサブフィールド３１０に数値情報が格納される。

（２）中間タイプ
中間タイプの業務、より詳しくは中間タイプの業務の消込２２に応じて、前身レコードが作成され、通知２３に応じて自身レコードが作成される。中間タイプの業務の通知２３に応じて作成される自身レコードにおいては、この自身レコードの計上サブフィールド３０５のＰｌｕｓサブフィールド３０７、及び消込サブフィールド３０６のＰｌｕｓサブフィールド３１０に数値情報が格納される。

（３）終点タイプ
終点タイプの業務、より詳しくは終点タイプの業務の消込２４に応じて、前身レコードが作成されるとともに、自身レコードも作成される。終点タイプの業務の消込２４に応じて作成される自身レコードにおいては、この自身レコードの計上サブフィールド３０５のＰｌｕｓサブフィールド３０７に数値情報が格納されるが、及び消込サブフィールド３０６のＰｌｕｓサブフィールド３１０に数値情報は格納されない。

［１．８．複数の受払、複数の業務フロー］
一つの業務が有する受払（通知、消込）は必ずしも一つずつに限られるものではない。一つの業務が２以上の通知を複数の次工程である業務に発し、及び／又は２以上の消込を複数の前工程である業務に返すこともあり得る。

図４（Ａ）は、複数の消込を生じさせる業務を有する業務フローの例を示している。業務Ｎは、２つの異なる業務、業務Ｌ及び業務Ｍの通知５１，５２に対応してそれぞれ消込６１，６２を生成させる。

図４（Ｂ）は、複数の通知を送る業務を有する業務フローの例を示している。業務Ｏは、２つの異なる業務、業務Ｐ及び業務Ｑに対する通知５３，５４を生成する。業務Ｐ及び業務Ｑは、それぞれ消込６３，６４を生成し受払を行う。

なお、図示はしていないが、複数の消込を生じさせるとともに、複数の通知を送る業務もあり得る。各業務が生じさせる通知の数、消込の数は、どのように業務フローを設計するかによって定まるものであり、何らの制限はない。

一つの業務が複数の通知又は消込を有する場合には、複数の業務フローが存在することになる。図４（Ａ）では、通知５１及び消込６１を含む第１の業務フロー７１と、通知５２及び消込６２を含む第２の業務フロー７２が存在する。なお、図中業務フロー毎に矢印を変えて示している。第１の業務フロー７１においては、業務Ｎは終点タイプの業務となる。

同様に、図４（Ｂ）では、通知５３及び消込６３を含む第１の業務フロー７３と、通知５４及び消込６４を含む第２の業務フロー７４が存在する。なお、図中業務フロー毎に矢印を変えて示している。第２の業務フロー７４においては、業務Ｏは始点タイプの業務となる。

複数の業務フローが存在する場合には、各業務フロー毎に業務フローテーブルが設けられる。図５に２つの業務フローを含む場合の構成例を示す。

この例では、６つの業務Ｒ，Ｓ，Ｔ，Ｕ，Ｖ，Ｗにより全体の業務活動が構成されている。

業務Ｒ，Ｓの間では、通知５５及び消込６５が生成され、業務Ｓ，Ｔの間では、通知５６及び消込６６が生成され、業務Ｔ，Ｕの間では、通知５７及び消込６７が生成される。これら業務Ｒ，Ｓ，Ｔ，Ｕ及び通知５５〜５７、消込６５〜６７は一つの業務フロー７５を構成する。業務フロー７５に含まれる通知５５〜５７及び消込６５〜６７に対応するレコードは、業務フローテーブル２０１に格納される。

一方、業務Ｓ，Ｖ，Ｗは、業務フロー７５とは別の業務フロー７６を構成する。すなわち、業務Ｓ，Ｖの間では、通知５８及び消込６８が生成され、業務Ｖ，Ｗの間では、通知５９及び消込６９が生成される。これら業務Ｓ，Ｖ，Ｗ及び通知５８〜５９、消込６８〜６９は別の一つの業務フロー７６を構成する。業務フロー７６に含まれる通知５８〜５９及び消込６８〜６９は、前述の業務フローテーブル２０１とは別の業務フローテーブル２０２に格納される。

異なる業務フローテーブルは、業務フローテーブルを構成する必要要素、すなわち自身業務区別ナンバーフィールド３０２と、前身業務区別ナンバーフィールド３０３と、ターゲットフィールド３０４のうち消込サブフィールド３０６を最低限備えていれば、その他はテーブルを構成するフィールドが異なっていても構わない。なお、論理的に業務フロー毎にレコードが区別可能であれば、例えば、各レコードに業務フローＩＤフィールドを付すなどして区別可能とすれば、同一のテーブルデータとして業務フローテーブル２０１及び業務フローテーブル２０２を記憶保持するようにしても構わない。

上記のような業務フローテーブルを用いることにより、あらゆる種類の業務の実行を、通知及び消込の業務フローテーブルへの記述又は記録の処理と置き換えることができ、これら処理をプログラム化することによって業務活動全体のシステム化、プログラム化を行うことができる。そのため、本発明よれば、業務管理システムの開発工数を劇的に減少させ、開発にかかる時間及び費用を低減させることが可能となる。

また、業務内容の変更が生じた場合にも、本発明にかかる技術を提供することにより、プログラムやデータベースの大幅な改変を伴うことなく、業務内容の変更を反映したシステムの修正が行えるようになる。

［２．本実施の形態にかかるシステムの例］
次に、本実施の形態にかかる一実施例として、第１の実施の形態にかかる業務管理システムの例を説明する。

［２．１．業務管理システムが扱う業務内容］
図６は、第１の実施の形態にかかるの業務管理システムが扱う業務内容の一例を説明する図である。このシステムが扱う業務内容は、以下の７つの業務、すなわち、業務Ａ、受注、出荷指示、出荷、業務Ｂ、補充発注、業務Ｃによって構成されている。

業務Ａ、受注、出荷指示、出荷、業務Ｂは第１の業務フロー７７を構成しており、これら業務間において通知６０１〜６０４及び消込７０１〜７０４が行われ、これら通知６０１〜６０４及び消込７０１〜７０４に対応するレコードは、第１業務フローテーブル５０１に順次追加され、格納される。

また、出荷指示、補充発注、業務Ｃは第２の業務フロー７８を構成しており、これら業務間において通知６０５、６０６及び消込７０５、７０６が行われ、これら通知及び消込に対応するレコードは、第２業務フローテーブル５０２に書き込まれる。

［２．２．業務管理システムの構成例］
図７は、本例の業務管理システム８０のシステム構成例を示す図である。この例においては、業務管理システム８０は、通信網８００に接続された管理サーバ８０１と、通信網８００に接続され、或いは接続可能な、上記７つの業務に対応する端末装置８０２によって構成される。

［２．２．１． 通信網］
通信網８００は、有線・無線、専用回線・交換回線を問わず、これに接続されている装置がそれぞれ目的とする装置に対しセッションを確立したときにその装置間での情報の送受を可能とするように作用する。通信網８００は、インターネットのように、ゲートウエイを介して複数のネットワークが組み合わされて実現しても構わない。また、その接続についてもいわゆるバックボーンといわれる基幹線に直接接続せずとも、ＰＰＰ接続などによって一時的に接続してあっても、セッションを確立したときにその間で情報の送受ができるようになっていれば構わない。なお、上記「通信網」は専用回線を固定的に張りめぐらせたような、交換機、スイッチ、ルータなど経路切り替え手段を用いない通信網も含むものとする。

［２．２．２．業務管理サーバ］
業務管理サーバ８０１は、演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している装置であって、例えばコンピュータ、ワークステーションなどの情報処理装置である。前記ＲＯＭ、若しくはハードディスク装置などに情報処理装置を業務管理サーバ８０１として機能させるためのプログラム、又は業務管理方法をコンピュータに実行させるためのプログラムが記憶されており、このプログラムを主メモリ上に載せ、ＣＰＵがこれを実行することにより業務管理サーバ８０１が実現され、若しくは業務管理方法が実行される。また、上記プログラムはかならずしも情報処理装置内の記憶装置に記憶されていなくともよく、外部の装置（例えば、ＡＳＰ（アプリケーション・サービス・プロバイダのサーバなど））から提供され、これを主メモリに乗せる構成であってもよい。

業務管理サーバ８０１は、各端末装置８０２からの入力に応じて、業務フローテーブルを記憶、更新、レコードの追加をするとともに、業務フローテーブルを参照して、業務の完了を判定する機能を有する。具体的には、各業務における通知、消込に対応する前身レコード、自身レコードを生成し、業務フローテーブルに追加するとともに、業務フローテーブルの消込サブフィールドの数値情報に基づいて、業務の未完了／完了を判定し、必要に応じて判定結果を端末装置８０２及び／又は業務管理サーバ８０１に接続された出力装置（モニタ、プリンタなど図７において図略）に出力する。

図８は、業務管理サーバ８０１の構成例を示す機能ブロック図である。業務管理サーバ８０１は、処理実行部８１０と、テーブル記憶部８２０を有している。

処理実行部８１０は、各端末装置８０２からの入力内容に基づいて、テーブル記憶部８２０に格納されている業務フローテーブル５０１、５０２を更新するとともに、各端末装置８０２からの要求に応じてテーブル記憶部８２０に格納されている業務フローテーブル５０１、５０２を参照して、消込が行われていない、或いは消込が未完了な通知を各端末装置８０２に通知する。

処理実行部８１０は、上記７つの業務のそれぞれに対応する、業務Ａ処理部８１２、受注処理部８１３，出荷指示処理部８１４，業務Ｂ処理部８１５、出荷処理部８１６，補充発注処理部８１７、業務Ｃ処理部８１８を有すると共に、これら各処理部８１２〜８１８の起動、終了を制御するコントローラ部８１１とを有している。

各処理部８１２〜８１８は対応する業務の内容に応じて、業務フローテーブルへのレコードの追加を実行する。各処理部には予め業務フローテーブルが対応付けされており、対応付けされた業務フローテーブルにのみレコードの追加を行う。但し、複数の業務フローに対応付けされている業務のための処理部は、複数の業務フローテーブルにレコードの追加を行う。

コントローラ部８１１は、端末装置８０２と各処理部８１２〜８１８との情報の受け渡しを仲介する機能を有する。例えば、受注業務用の端末装置８０２から処理要求をコントローラ部８１１が受け取ると、受注処理部８１３を起動させる。起動した受注処理部８１３は、テーブル記憶部８２０の第１業務フローテーブル５０１を参照して、受注処理が未完了である前工程の処理、すなわち、消込７０１が完了していない業務Ａの通知６０１を抽出してコントローラ部８１１に渡す。コントローラ部８１１は、通信網８００を介して、消込７０１が完了していない業務Ａを示す情報（例えば、未完了の業務ＡをリストにしたＨＴＭＬドキュメント）を受注業務用の端末装置８０２に送信する。

テーブル記憶部８２０は、その業務管理システムが扱う業務フローテーブルを格納、若しくは記憶している。この例では、テーブル記憶部８２０は、第１業務フローテーブル５０１、及び第２業務フローテーブル５０２を格納、若しくは記憶する。なお、テーブル記憶部８２０は、その業務管理システムが扱う業務全体に含まれる業務フローの数と同数の業務フローテーブルを有することとなる。

業務フローテーブルは、そのテーブルが一のファイルで構成されるものであっても、各レコードが業務フロー毎に区別可能であれば、一つの業務フローテーブルではなく、複数の業務フローテーブルに相当する。

［２．２．３．端末装置］
端末装置８０２は、演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している装置であって、業務管理サーバ８０１と通信可能な情報処理装置である。例えばネットワーク接続機能を有するコンピュータ、ワークステーション、移動体通信端末、ＰＤＡ（Personal Digital Assistant）などが端末装置８０２となりうる。。

端末装置８０２は、業務管理サーバ８０１とクライアント／サーバの関係にあり、端末装置８０２からの要求に応じて業務管理サーバ８０１が諸処理を実行し、業務管理サーバ８０１はその実行結果を端末装置８０２に返す。

端末装置８０２は、各業務の実行情報の入力を行わせる入力インターフェイスを操作者に提供し、この入力インターフェイスに入力された情報を業務管理サーバ８０１に送信する。また、端末装置８０２は、業務管理サーバ８０１から未完了の業務を通知され、この通知に応じて未完了の情報を操作者に示す機能を有している。

［２．３．業務管理システムの動作例］
次に、上記業務管理システムの動作例について、図９から図１９を参照しながら説明する。

この業務管理システムにおいて、まず第１の業務フローの始点業務である業務Ａが業務Ａの担当者によって実行され、業務Ａの担当者は業務Ａ用の端末装置８０２に業務Ａの実行結果を入力する。図９は、業務Ａ用の端末装置８０２が表示する入力インターフェイス画面の一例である。この入力インターフェイス画面は、商品選択ボックス９０１と、個数入力ボックス９０２と、ＯＫボタン９０３と、キャンセルボタン９０４とを有している。この入力インターフェイス画面が端末装置８０２に表示されているときに、操作者が端末装置８０２のキーボードやポインティングデバイスを操作して、商品選択ボックス９０１と、個数入力ボックス９０２に、実行した業務Ａの内容に応じた入力を行った後、ＯＫボタン９０３を活性化させると、業務Ａ用の端末装置８０２は、業務Ａの実行内容として商品選択ボックス９０１と、個数入力ボックス９０２に入力された情報を業務管理サーバ８０１に送信する。

業務Ａ用の端末装置８０２からの送信を受信した業務管理サーバ８０１、より詳しくは処理実行部８１０は、業務Ａ処理部８１２を起動させる。起動した業務Ａ処理部８１２は、第１の業務フロー７７に対応する業務フローテーブルである、第１業務フローテーブル５０１にレコードを追加する。図１０は、業務Ａ処理部８１２がレコードを追加した状態の第１業務フローテーブル５０１の例を示す。

図１０に示す第１業務フローテーブル５０１は、図３に示す業務フローテーブル２００と同様に、自身業務区別ナンバーフィールド３０２と、前身業務区別ナンバーフィールド３０３と、ターゲットフィールド３０４とを有するとともに、商品選択ボックス９０１の入力に対応する「Ｉｔｅｍ」フィールド１００１を有している。

また、上記ターゲットフィールド３０４は、計上サブフィールド３０５と、消込サブフィールド３０６とを有しており、計上サブフィールド３０５と消込サブフィールド３０６とはそれぞれ、「Ｐｌｕｓ（プラス）」サブフィールド３０７，３１０と、「Ｍｉｎｕｓ（マイナス）」サブフィールド３０８、３１１と、「Ｕｎｉｔ（単位）」サブフィールド３０９，３１２を有することは、図３に示した業務フローテーブル２００と同様である。

さて、業務Ａは始点タイプの業務であるため、業務Ａ処理部８１２は自身レコードであるレコード１００２Ａを追加するが、前身レコードの追加は行わない。

自身レコードであるレコード１００２Ａにおいて、自身業務区別ナンバーフィールド３０２には、業務Ａを示す業務ＩＤナンバーとともに、複数回、業務Ａが行われた場合に、各回の業務を識別するためのシリアルナンバー（図中［０１］と表示している）が格納されている。前身業務区別ナンバーフィールド３０２には、このレコードが自身レコードであるため何も格納されない。Ｉｔｅｍフィールド１００１には、端末装置８０２から通知された商品である「テレビＬ」を識別する情報（例えば、製品番号）が格納される。

また、レコード１００２Ａのターゲットフィールド３０４の計上サブフィールド３０５におけるＰｌｕｓサブフィールド３０７、及び消込サブフィールド３０６におけるＰｌｕｓサブフィールド３１０には、端末装置８０２から通知された数値情報（個数入力ボックス９０２に入力された情報に対応する）である「１０」が格納される。

上記レコード１００２Ａの追加を終えると、業務Ａ処理部８１２は待機状態になり、次の起動命令を待ち受ける。

上記レコード１００２Ａの追加が終了すると、業務Ａの次工程である受注に割り当てられた端末装置８０２に、図１１に示すような入力インターフェイス画面が表示される。図１１は、受注に割り当てられた端末装置８０２に表示される入力インターフェイス画面の一例を示す図である。図に示す例において、入力インターフェイス画面は、消込の行われていない前工程の業務の内容を示す、商品表示フィールド１１０１と、個数表示フィールド１１０２と、受注について実行した内容を入力する商品選択ボックス１１０３と、個数入力ボックス１１０４と、ＯＫボタン１１０５と、キャンセルボタン１１０６とを有している。商品表示フィールド１１０１と、個数表示フィールド１１０２との表示内容は、第１業務フローテーブル５０１のレコード１００２Ａに基づいて表示される。

受注の担当者は、商品表示フィールド１１０１と、個数表示フィールド１１０２との表示内容を見て、テレビＬ１０個について受注が未処理であることを知り、受注の処理を行う。図１２に、受注の担当者が受注の処理を行った結果が、前記の入力インターフェイス画面に入力された画面例を示す。この例では、テレビＬ１０個すべてについて受注処理したものとして、商品選択ボックス１１０３に「テレビＬ」が入力され、個数入力ボックス１１０４に数値情報「１０」が入力された。

図１２に示す画面状態で、受注に割り当てられた端末装置８０２の操作者が、ＯＫボタン１１０５を活性化させると、受注用の端末装置８０２は、受注の実行内容として商品選択ボックス１１０３と、個数入力ボックス１１０４に入力された情報を業務管理サーバ８０１に送信する。

受注用の端末装置８０２からの送信を受信した業務管理サーバ８０１、より詳しくは処理実行部８１０は、受注処理部８１３を起動させる。起動した受注処理部８１３は、第１の業務フロー７７に対応する業務フローテーブルである、第１業務フローテーブル５０１に新たなレコードを追加する。図１３は、受注処理部８１３がレコードを追加した状態の第１業務フローテーブル５０１の例を示す。

さて、受注は中間タイプの業務１２であるため、受注処理部８１３は前身レコードであるレコード１００２Ｂ，及び自身レコードであるレコード１００２Ｃを追加する。

前身レコードであるレコード１００２Ｂにおいて、自身業務区別ナンバーフィールド３０２には、受注を示す業務ＩＤナンバーとともに、複数回受注が行われた場合に、各回の業務を識別するためのシリアルナンバー（図中［０１］と表示している）が格納される。前身業務区別ナンバーフィールド３０３には、この前身レコードの消込の対象、或いは相手方である業務、すなわち業務Ａを示す業務ＩＤナンバーとともにそのシリアルナンバー（図中［０１］と表示している）が格納される。Ｉｔｅｍフィールド１００１には、受注に割り当てられた端末装置８０２から通知された商品である「テレビＬ」を識別する情報（例えば、製品番号）が格納される。

また、レコード１００２Ｂのターゲットフィールド３０４の計上サブフィールド３０５におけるＰｌｕｓサブフィールド３０７には数値情報は格納されない。一方、消込サブフィールド３０６におけるＭｉｎｕｓサブフィールド３１１には、受注に割り当てられた端末装置８０２から通知された数値情報である「１０」が格納される。ここで、レコード１００２ＡのＰｌｕｓサブフィールド３１０に格納されている数値情報と、上記Ｍｉｎｕｓサブフィールド３１１に格納されている数値情報とを比較することにより、業務Ａで生じた内容が受注ですべて処理されたか否かを判断することが可能となる。

さて、中間タイプの業務に対応する受注処理部８１３は、上記のレコード１００２Ｂに加えて、さらに自身レコードであるレコード１００２Ｃを追加する。レコード１００２Ｃにおいて、自身業務区別ナンバーフィールド３０２には、受注を示す業務ＩＤナンバーとともに、複数回業務Ａが行われた場合に、各回の業務を識別するためのシリアルナンバー（図中［０１］と表示している）が格納されている。前身業務区別ナンバーフィールド３０３には、このレコードが自身レコードであるため何も格納されない。Ｉｔｅｍフィールド１００１には、端末装置８０２から通知された商品である「テレビＬ」を識別する情報（例えば、製品番号）が格納される。

また、レコード１００２Ａのターゲットフィールド３０４の計上サブフィールド３０５におけるＰｌｕｓサブフィールド３０７及び消込サブフィールド３０６におけるＰｌｕｓサブフィールド３１０には、受注に割り当てられた端末装置８０２から通知された数値情報である「１０」が格納される。この自身レコードは、次工程の業務である出荷指示の消込の目標になるものである。

上記レコード１００２Ｂ及びレコード１００２Ｃの追加を終えると、受注処理部８１３は待機状態になり、次の起動命令を待ち受ける。

次に、上記受注処理部８１３が行った処理内容と同様に、出荷指示業務の実行に応じて、出荷指示処理部８１４は、第１業務フローテーブル５０１に前身レコードと自身レコードを追加する。図１４に、出荷指示処理部８１４が前身レコードと自身レコードとを追加した第１業務フローテーブル５０１の例を示す。この例では、前身レコードとしてレコード１００２Ｄが追加され、自身レコードとしてレコード１００２Ｅが追加される。この前身レコード１００２Ｄと、先の自身レコード１００２Ｃとを対比することにより、出荷指示業務の消込の完了が判定できる。また、この自身レコード１００２Ｅは、次工程の業務である出荷の消込の目標になるものである。

なお、出荷指示は、第１業務フロー７７の中間タイプの業務であると共に、第２業務フロー７８の始点タイプの業務でもある。従って、出荷指示処理部８１４は、第１業務フローテーブル５０１に前身レコードと自身レコードを追加するとともに、第２業務フローテーブル５０２にも、レコードの追加を行う。この第２業務フローテーブル５０２へのレコードの追加については、後述する。

さて、上記受注処理部８１３が行った処理内容と同様に、「出荷指示」の次工程として行われる「出荷」業務の実行に応じて、出荷処理部８１６は、第１業務フローテーブル５０１に前身レコードと自身レコードを追加する。図１５に、出荷処理部８１６が前身レコードと自身レコードとを追加した第１業務フローテーブル５０１の例を示す。この例では、前身レコードとしてレコード１００２Ｆが追加され、自身レコードとしてレコード１００２Ｇが追加される。この前身レコード１００２Ｆと、先の自身レコード１００２Ｅとを対比することにより、出荷指示業務の消込の完了が判定できる。また、この自身レコード１００２Ｇは、次工程の業務である業務Ｂの消込の目標になるものである。

出荷の次工程である業務Ｂは、第１業務フロー７７における終点タイプの業務である。業務Ｂに対応する業務Ｂ処理部８１５は、第１業務フローテーブル５０１に前身レコードと自身レコードを追加する。図１６に、業務Ｂ処理部８１５が前身レコードと自身レコードとを追加した第１業務フローテーブル５０１の例を示す。この例では、前身レコードとしてレコード１００２Ｈが追加され、自身レコードとしてレコード１００２Ｉが追加される。この前身レコード１００２Ｈと、先の自身レコード１００２Ｇとを対比することにより、出荷業務の消込の完了が判定できる。また、この自身レコード１００２Ｉは、次工程が存在せず、消込の必要がないため、消込サブフィールド３０６におけるＰｌｕｓサブフィールド３１０には数値情報が格納されない。

以降、業務Ａから業務Ｂまでの第１業務フロー７７に属する業務が行われることに応じて、第１業務フローテーブル５０１にレコードが順次追加されていくこととなる。図１７は、図１６の状態の後に新たな業務Ａが行われ、これに応じて２回の受注業務が行われた場合の第１業務フローテーブル５０１の例を示す。ここでは、新たな業務Ａに対応する業務Ａの自身レコード１００２Ｊが業務Ａ処理部８１２により追加されているとともに、第１の新たな受注業務（図中、シリアルナンバー［０２］と表示した）に対応する前身レコード１００２Ｋ，自身レコード１００２Ｌ及び、第２の新たな受注業務（図中、シリアルナンバー［０２］と表示した）に対応する前身レコード１００２Ｍ，自身レコード１００２Ｎが追加される。

この例においては、レコード１００２Ｊの消込はレコード１００２Ｋ，１００２Ｍによって判定される。ここでは、レコード１００２ＪのＰｌｕｓサブフィールド３１０の数値情報と、レコード１００２Ｋ，１００２ＭのＭｉｎｕｓサブフィールド３１１の数値情報の合計とを比較することにより、業務Ａの完了を判定する。このように、１回の前工程の業務を複数回の次工程の業務で消込する場合であっても、本発明によれば容易に消込完了の判定をすることができる。

また、図には示さなかったが、逆に複数回の前工程の業務を一回の次工程の業務で消込する場合であっても、本発明によれば容易に消込完了の判定をすることができる。

さて、出荷指示が、第１業務フロー７５の中間タイプの業務であると共に、第２業務フロー７８における始点タイプの業務でもあることは先に述べたとおりである。従って、出荷指示処理部８１４は、第１業務フローテーブル５０１に前身レコードと自身レコードを追加するとともに、第２業務フローテーブル５０２にも、レコードの追加を行う。以下、第２業務フロー７８に関する本業務管理システムの動作について説明する。

出荷指示が実行されると、出荷指示処理部８１４は、第１業務フローテーブル５０１に前身レコードと自身レコードを追加する一方、第２業務フローテーブル５０２にも、レコードの追加を行う。図１８は、出荷指示処理部８１４がレコードを追加した状態の第２業務フローテーブル５０２の例を示す。なお、図１８に示す第２業務フローテーブル５０２は、第１業務フローテーブル５０１と同様のフィールドを有するものとして図示したが、各業務フローテーブルが有するフィールドは必ずしも一致している必要はなく、各業務フローに合わせたフィールド構成を取るようにしても構わない。

さて、出荷指示は第２業務フロー７８においては始点タイプの業務であるため、出荷指示処理部８１４は自身レコードであるレコード１８０２Ａのみを追加する。前身レコードの追加は行わない。レコード１８０２Ａにおいて、自身業務区別ナンバーフィールド３０２には、出荷指示を示す業務ＩＤナンバーとともに、複数回出荷指示が行われた場合に、各回の業務を識別するためのシリアルナンバー（図中［０１］と表示している）が格納されている。前身業務区別ナンバーフィールド３０２には、このレコードが自身レコードであるため何も格納されない。Ｉｔｅｍフィールド１００１には、端末装置８０２から通知された商品である「テレビＬ」を識別する情報（例えば、製品番号）が格納される。

また、レコード１８０２Ａのターゲットフィールド３０４の計上サブフィールド３０５におけるＰｌｕｓサブフィールド３０７及び消込サブフィールド３０６におけるＰｌｕｓサブフィールド３１０には、端末装置８０２から通知された数値情報である「１０」が格納される。上記レコード１８０２Ａの追加を終えると、出荷指示処理部８１４は待機状態になり、次の起動命令を待ち受ける。

上記レコード１８０２Ａの追加が終了すると、第２業務フロー７８における出荷指示の次工程である補充発注の処理が行われる。そして、補充発注を実行した情報が、補充発注用の端末装置８０２から送信されると、この情報を受信した業務管理サーバ８０１、より詳しくはコントローラ部８１１は、補充発注処理部８１７を起動させる。起動した補充発注処理部８１７は、第２の業務フロー７８に対応する業務フローテーブルである、第２業務フローテーブル５０２に新たなレコードを追加する。図１９は、補充発注処理部８１７がレコードを追加した状態の第２業務フローテーブル５０２の例を示す。

図１９に示されるように、補充発注は中間タイプの業務であるため、補充発注処理部８１７は前身レコードであるレコード１８０２Ｂ，及び自身レコードであるレコード１８０２Ｃを追加する。

前身レコードであるレコード１８０２Ｂにおいて、自身業務区別ナンバーフィールド３０２には、補充発注を示す業務ＩＤナンバーとともに、複数回受注が行われた場合に、各回の業務を識別するためのシリアルナンバー（図中［０１］と表示している）が格納される。前身業務区別ナンバーフィールド３０３には、この前身レコードの消込の対象、或いは相手方である業務、すなわち出荷指示を示す業務ＩＤナンバーとともにそのシリアルナンバー（図中［０１］と表示している）が格納される。Ｉｔｅｍフィールド１００１には、補充発注に割り当てられた端末装置８０２から通知された商品である「テレビＬ」を識別する情報（例えば、製品番号）が格納される。

また、レコード１８０２Ｂのターゲットフィールド３０４の計上サブフィールド３０５におけるＰｌｕｓサブフィールド３０７には数値情報は格納されない。一方、消込サブフィールド３０６におけるＭｉｎｕｓサブフィールド３１１には、補充発注に割り当てられた端末装置８０２から通知された数値情報である「１０」が格納される。ここで、レコード１８０２ＡのＰｌｕｓサブフィールド３１０に格納されている数値情報と、上記Ｍｉｎｕｓサブフィールド３１１に格納されている数値情報とを比較することにより、出荷指示で生じた内容が補充発注ですべて処理されたか否かを判断することが可能となる。

さて、中間タイプの業務に対応する補充発注処理部８１７は、上記のレコード１８０２Ｂに加えて、さらに自身レコードであるレコード１８０２Ｃを追加する。レコード１８０２Ｃにおいて、自身業務区別ナンバーフィールド３０２には、補充発注を示す業務ＩＤナンバーとともに、複数回補充発注が行われた場合に、各回の業務を識別するためのシリアルナンバー（図中［０１］と表示している）が格納されている。前身業務区別ナンバーフィールド３０３には、このレコードが自身レコードであるため何も格納されない。Ｉｔｅｍフィールド１００１には、端末装置８０２から通知された商品である「テレビＬ」を識別する情報（例えば、製品番号）が格納される。

上記レコード１８０２Ｂ，１８０２Ｃの追加が終了すると、第２業務フロー７８における補充発注の次工程である業務Ｃの処理が行われる。業務Ｃを実行した情報が、業務Ｃ用の端末装置８０２から送信されると、この情報を受信した業務管理サーバ８０１、より詳しくはコントローラ部８１１は、業務Ｃ処理部８１８を起動させる。

補充発注の次工程である業務Ｃは、第２業務フロー７８における終点タイプの業務である。業務Ｃに対応する業務Ｃ処理部８１８は、第２業務フローテーブル５０２に前身レコードと自身レコードを追加する。図２０に、業務Ｃ処理部８１８が前身レコードと自身レコードとを追加した第２業務フローテーブル５０２の例を示す。この例では、前身レコードとしてレコード１８０２Ｄが追加され、自身レコードとしてレコード１８０２Ｅが追加される。この前身レコード１８０２Ｄと、先の自身レコード１８０２Ｃとを対比することにより、補充発注業務の消込みの完了が判定できる。また、この自身レコード１８０２Ｅは、次工程が存在せず、消込の必要がないため、消込サブフィールド３０６におけるＰｌｕｓサブフィールド３１０には数値情報が格納されない。

以降、出荷指示から業務Ｃまでの第２業務フロー７８に属する業務が行われることに応じて、第２業務フローテーブル５０２にレコードが順次追加されていくこととなる。

このように、本実施の形態にかかる業務管理システムは、企業などの活動主体が行う業務活動の中に、複数の業務フローが存在する場合には、それぞれの業務フローに対応した業務フローテーブルを設け、業務フロー毎に対応する業務フローテーブルにレコードを追加することにより、簡易且つ柔軟に業務の進行管理（消込の完了の判定）を行うことができる。

以上で、本実施の形態にかかる業務管理システムの動作例の説明を終了する。

［第２の実施の形態］
次に、本発明にかかる業務管理システムの第２の実施の形態について説明する。

第２の実施の形態にかかる業務管理システムの構成は、図７に示す構成と同様である。端末装置８０２の構成、機能、動作、は基本的に第１の実施の形態と同様である。但し、業務管理サーバの機能、構成が第１の実施の形態と異なっている。

図２３は、第２の実施の形態にかかる業務管理サーバの構成例を示す機能ブロック図である。業務管理サーバ２３０１は、第１の実施の形態の業務管理サーバ８０１と同様に、演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している装置であって、例えばコンピュータ、ワークステーションなどの情報処理装置である。前記ＲＯＭ、若しくはハードディスク装置などに情報処理装置を業務管理サーバ２３０１として機能させるためのプログラム、又は業務管理方法をコンピュータに実行させるためのプログラムが記憶されており、このプログラムを主メモリ上に載せ、ＣＰＵがこれを実行することにより業務管理サーバ２３０１が実現され、若しくは業務管理方法が実行される。また、上記プログラムはかならずしも情報処理装置内の記憶装置に記憶されていなくともよく、外部の装置（例えば、ＡＳＰ（アプリケーション・サービス・プロバイダのサーバなど））から提供され、これを主メモリに乗せる構成であってもよい。

業務管理サーバ２３０１は、処理実行部２３１１、及びテーブル記憶部２３２０を有している。

テーブル記憶部２３２０は、オリジンテーブル２３２１と、コンビネーションテーブル２３２２と、フローコアテーブル２３２３と、ストックテーブル２３２４と、バランステーブル２３２５とを記憶する。但し、フローコアテーブル２３２３以外は、必須の構成要素ではなく、これらテーブルがなくとも業務管理サーバ２３０１は、業務管理方法を実行することは可能である。

以下、上記のテーブルについて説明する。

オリジンテーブル２３２１は、キーが一つになるまで正規化されたマスタテーブルである。オリジンテーブル２３２１は、場合によって複数キーを持つ事も可能だが、他の原本との持ち合いは不可とするように構成される。オリジンテーブル２３２１は、例えば、取引先マスターテーブル、社員マスターテーブル、金融機関テーブルである。

図２４Ａに、オリジンテーブル２３２１の例である取引先マスターテーブルを示す。この例では、一つのレコードは、会社コード、会社名、住所、電話番号をそれぞれ格納するフィールドを有しており、会社コードは取引先を一意に特定できる情報が割り当てられる。

次に、コンビネーションテーブル２３２２について説明する。コンビネーションテーブル２３２２は、各原本（オリジンテーブル２３２１）の組み合わせを利用したい場合に設定するテーブルである。コンビネーションテーブル２３２２を備えることにより、オリジンテーブルに基づいたグループ化、階層化、キーの範囲制御などが行える。コンビネーションテーブル２３２２の例としては、例えば、品目マスタテーブルなどである。

図２４Ｂは、コンビネーションテーブルの元となる２つのオリジンテーブルの例を示す。図の上段に示したオリジンテーブル２３２１は、取引先を特定する情報である取引先コードをキーとするテーブルで、キーに対応する取引先の名称（取引先名）、電話番号（ＴＥＬ）、住所を格納するテーブルである。図の下段に示したオリジンテーブル２３２１は、地域を特定する情報である地域コードをキーとするテーブルで、当該地域名、地域責任者氏名を格納する。

図２４Ｃは、グループ化のためのコンビネーションテーブル２３２１の例を示した図である。ここで示すコンビネーションテーブル２３２１は、ヘッダテーブルと明細テーブルの２つのテーブルで構成されるものとする。図２４Ｃ上段のテーブルは、グループを一意に特定する情報であるグループコードキーを格納するヘッダテーブルである。図２４Ｃ下段のテーブルは、各グループコードキーに対応づけられた、地域コードと、取引先コードとを格納する明細テーブルである。地域コードは、図２４Ｂ下段に示したオリジンテーブルの地域コードに対応し、取引先コードは、図２４Ｂ上段に示したオリジンテーブルの取引先コードに対応する。

次に、階層化のためのコンビネーションテーブル２３２２の例を図２４Ｄに示す。図２４Ｄ上段のテーブルは、親と親に属する子という階層を特定する親グループコードと子グループコードを対応づけて格納したヘッダテーブルである。図２４Ｄ下段のテーブルは、上記ヘッダテーブルの親グループコード、子グループコードのそれぞれに対応づけて取引先コードを格納する明細テーブルである。取引先コードは、図２４Ｂ上段に示したオリジンテーブルの取引先コードに対応する。

次に、キーの範囲制御のためのコンビネーションテーブル２３２２の例を図２４Ｅに示す。ここでは、キーの範囲制御とは、同一のキーについて範囲ごとに異なる情報を持たせることをいう。図２４Ｅ上段のテーブルは、範囲を識別する情報である子コードと、これに対応づけられた名称を格納したヘッダテーブルである。図２４Ｅ下段のテーブルは、上記子コードと、それぞれの子コードに対応づけられた商品名、取引先コード、範囲（ここでは、fromとtoの２つの値）、単価を格納する明細テーブルである。取引先コードは、図２４Ｂ上段に示したオリジンテーブルの取引先コードに対応する。

次に、フローコアテーブル２３２３について説明する。フローコアテーブル２３２３は同一フロー上の全ての業務の実行結果をデータを持つトランザクションテーブルであって、第１の実施の形態における業務フローテーブル５０１，５０２に相当する。フローコアテーブル２３２３テーブル内に残を持つことは基本的には行わない。フローコアテーブル２３２３は、業務フローごとに一つ設けられる。

図２５は、第１の実施の形態で用いる業務フローテーブルの例であって、フローコアテーブル２３２３との比較のためにここに掲げた。ここに掲げた業務フローテーブルの各レコードは、「ＧＹＯＵＭＵコード」、「Ｒタイプ」、「伝票No.（キー）」、「行Ｎｏ．」、「会社コード」、「品目」、「数量」、「発注Ｎｏ．」、「発注日」、「希望納期」、「入荷日」、「請求日」の各項目についての情報を格納するフィールドを有している。なお、図２５に示した例では、前述した自身レコードか前身レコードであるかは「行Ｎｏ．」により識別する構成である。

次に、フローコアテーブル２３２３の例を図２６に示す。図２６は、図２５の業務フローテーブルに対応する、フローコアテーブル２３２３の構成例を示す図である。フローコアテーブル２３２３は、「ＧＹＯＵＭＵコード」、「Ｒタイプ」、「伝票No.（キー）」、「行Ｎｏ．」、「会社コード」、「品目」、「数量」の各フィールドを有するが、「発注Ｎｏ．」、「発注日」、「希望納期」、「入荷日」、「請求日」のフィールドは有していない。これらのフィールドを省くことによって、データの冗長性を回避することができ、読み出しなどのデータ処理速度の向上、記憶容量の削減などを図ることができる。

次に、ストックテーブル２３２４について説明する。ストックテーブル２３２４は、各業務独自のデータを保持するトランザクションテーブルである。図２７は、図２６に示すフローコアテーブル２３２３に基づいた、ストックテーブル２３２４の例であって、（Ａ）は、ＧＹＯＵＭＵコード「Ｇ１」を与えられた業務についてのストックテーブル２３２４の例であり、（Ｂ）は、ＧＹＯＵＭＵコード「Ｇ２」を与えられた業務についてのストックテーブル２３２４の例である。それぞれ、フローコアテーブル２３２３にはない「フィールド発注Ｎｏ．」、「発注日」、「希望納期」、「入荷日」を有する構成となっており、これらの情報を記憶、管理することが可能となる。なお、ストックテーブル２３２４をさらに複数のテーブルに分割するようにしてもよい。分割されたストックテーブルとして、ヘッダ、明細、拡張がある。図２８（Ａ）（Ｂ）は、図２７（Ａ）（Ｂ）のストックテーブル２３２４を拡張したストックテーブルの例を示す。図２８（Ａ）及び図２８（Ｂ）に示したストックテーブルは、元となったストックテーブル及び又はフローコアテーブルが有していない項目（図２８（Ａ）では、「伝票値引き」、図２８（Ｂ）では、「追加運賃」）を有している。このように拡張したストックーブルを用いることにより、所望の情報をストックテーブル或いはフローコアテーブルに関連づけて持つことが可能となる。

次に、バランステーブル２３２５について説明する。バランステーブル２３２５は、任意の複数の「業務」若しくは業務フローについての残を保持するテーブルである。バランステーブル２３２５の有するレコード数は、特定のオリジンテーブル２３２１もしくはコンビネーションテーブル２３２２のレコード数と一致する。図２９は、図２４Ｂ上段に示したオリジンテーブル２３２１（取引先マスタ）の各取引先コードについて、、１月末の残件数、２月末の残件数、３月末の残件数が記録されている。なお、これらの残件数は、フローコアテーブル２３２３の「数値」に基づいて、計算され格納される。

図２３に戻り、業務管理サーバ２３０１の構成例の説明を再開する。

処理実行部２３０１は、コントローラ部２３１１と、原本処理部２３３１、結合処理部２３３２，受払処理部２３３３、蓄積処理部２３３４、証憑処理部２３３５、帳票処理部２３３６，分析処理部２３３７とを有している。これら各部は、例えば、プログラム、或いはそのモジュールなどに相当する構成要素であって、必ずしも各部が独立したハードウエアである必要はない。

コントローラ部２３１１は、第１の実施の形態におけるコントローラ部８１１と同一の機能を有する構成要素であるので、詳細な説明は省略する。

原本処理部２３３１は、オリジンテーブル２３２１にデータを格納し、メンテナンスする処理を行う機能を有する。原本処理部２３３１は、各端末装置８０２或いは図示しない業務管理サーバ２３０１の入出力装置（例えば、キーボードおよび液晶ディスプレイ装置）に入力インターフェイスを提供し、この入力インターフェイスに従って担当者が入力した情報を、目的のオリジンテーブル２３２１に格納したり、修正を行ったりする。なお、入力インターフェイスには、基本型（カード、一覧）・拡張型（カード）・カレンダー型（カレンダー）の3つのタイプが用いられてよい。

結合処理部２３３２は、コンビネーションテーブル２３２２に、各端末装置８０２或いは図示しない業務管理サーバ２３０１の入出力装置（例えば、キーボードおよび液晶ディスプレイ装置）によって入力されたデータを格納し、メンテナンスする機能を有する。活用する側の「業務」の目的により、絞込型（非階層、階層）・ルール型・値返却型（非階層、階層）・ルール＆値返却型の6つのタイプが用意されている。

受払処理部２３３３は、業務の実行結果を示す入力に応じてフローコアテーブル２３２３に自身レコード、前身レコードを追加し、それらレコードのフィールドにデータを格納する機能を有し、第１の実施の形態の各処理部８１２〜８１８に対応する構成要素である。受払処理部２３３３は、一般に一つの業務に対して一つ設けられるが、複数の業務について一つの受払処理部２３３３で処理する構成としても構わない。

蓄積処理部２３３４は、受払処理以外のエントリーデータを格納、もしくは業務フロー間のデータ受渡を実行する機能を有する。蓄積処理部２３３４には、レジャー入力型・バランス更新型・フロー間受渡型・インポート型などがある。受払処理を補完する役割を有している。

証憑処理部２３３５は、受払を制御するための従属関係を構成し、また、再印刷を規制するような重要な伝票を作成する機能を有する。複数の明細を保持する伝票を1単位として扱い、伝票を跨る集計等は行わない。伝票はヘッダ1行型・2行型が用意されている。

帳票処理部２３３６，任意の一つの「業務」に対して、複数の明細を集計し、表示・印刷・ファイルを保存する機能を有する。一覧型・残型・滞留型・遅延型・優先度型・達成率型・超過型・停止型の8つのタイプが用意されている。帳票処理部２３３６はテーブル２３２１〜２３２５への書込は行わない。複数のフローコアからの集計を行う場合は、個別に追加する事もできる。

分析処理部２３３７は、任意の一つの業務フローの全体俯瞰（進行度合い、処理完了度合いの算出など）、またはバランステーブル２３２５のデータを、表示・印刷・ファイル保存する機能を有する。分析処理部２３３７は、グラフ等を用いてグラフィカルに表示し、グラフからグラフへの切り替え（CUBE）など、様々な角度からのデータ分析とドリルダウンを可能とする機能をさらに有していてもよい。テーブル２３２１〜２３２５への書込は行わない。複数の業務フローを対象とする場合は、追加する事もできる。 本実施の形態によれば、業務フローテーブルからの冗長性を廃することが可能となり、より迅速なデータ処理を可能とする。

［４．変形例、その他］
［４．１．将来の予測］
本発明にかかる業務管理システムは、将来の業務活動の結果を予測することにも用いることができる。図２１は、将来の業務活動の結果を予測する場合に用いる、業務フローテーブルの例を示す図である。この業務フローテーブル２１０１は、未発生フラグフィールド２１０２をさらに有していることを特徴とする。図示の例は、業務Ａが実行されたが、それ以降の受注から業務Ｂは行われていない時点で作成された業務フローテーブル２１０１の内容となっている。実際に生じた業務Ａについては、対応するレコードの未発生フラグフィールド２１０２に発生を示す情報（この例では「１」）を格納し、実際に生じていない受注から業務Ｂについては、対応するレコードの未発生フラグフィールド２１０２に未発生を示す情報（この例では「０」）を格納する。かかる業務フローテーブル２１０２のデータを参照することにより、将来受注から業務Ｂにおいて処理する必要のある商品及びその個数を算出することが可能となる。これにより、補充計画、購買計画などが容易に作成されるようになる。

なお、第２の実施の形態においても、フローコアテーブル２３２３に未発生フラグフィールド２１０２を追加し、或いは未発生フラグフィールド２１０２を有するストックテーブル２３２４を設けることにより、同様の変形を行うことが可能である。

［４．２．金銭的管理］
本発明にかかる業務管理システムは、予算や会計管理などの金銭的管理にも用いることができる。図２２は、金銭的管理を実行する場合に用いられる業務フローテーブルの例を示す図である。この業務フローテーブル２２０１は、金額フィールド２２０２をさらに有していることを特徴とする。金額フィールド２２０２は、ターゲットフィールド３０４と同様のサブフィールド構成を有しており、計上サブフィールド２２０３と、消込サブフィールド２２０４とを有している。これら計上サブフィールド２２０３と消込サブフィールド２２０４とはそれぞれ、「Ｐｌｕｓ（プラス）」サブフィールド２２０５，２２０８と、「Ｍｉｎｕｓ（マイナス）」サブフィールド２２０６、２２０９と、「Ｕｎｉｔ（単位）」サブフィールド２２０７，２２１０とを有している。

「Ｐｌｕｓ（プラス）」サブフィールド２２０５，２２０８と、「Ｍｉｎｕｓ（マイナス）」サブフィールド２２０６、２２０９に格納される情報は、ターゲットフィールド３０４の「Ｐｌｕｓ（プラス）」サブフィールド３０７，３１０と、「Ｍｉｎｕｓ（マイナス）」サブフィールド３０８、３１１とに格納されている数値情報を金銭に換算した値が格納される。例えば、テレビＬ１台の価格が５００００円であれば、ターゲットフィールド３０４側に「１０」と記述されていると、金銭フィールド２１０２側では「５０００００」という数値情報が格納される。かかる金銭フィールド２１０２を利用することにより、金銭的管理を行うことも可能となる。

なお、第２の実施の形態においても、フローコアテーブル２３２３に金額フィールド２２０２を追加し、或いは金額フィールド２２０２を有するストックテーブル２３２４を設けることにより、同様の変形を行うことが可能である。

（Ａ）は始点タイプに分類される業務、（Ｂ）は中間タイプに分類される業務、（Ｃ）は終点タイプに分類される業務を示す図 始点タイプの業務、一つの中間タイプの業務、及び終点タイプの業務が直列的に連結されて構成された業務フローの概念図 業務フローテーブルの具体的構成例を示す図 （Ａ）は、複数の消込を生じさせる業務を有する業務フローの例を示す図、（Ｂ）は、複数の通知を送る業務を有する業務フローの例を示す図 ２つの業務フローを含む場合の構成例を示す図 業務管理システムが扱う業務内容を説明する図 業務管理システムのシステム構成例を示す図 業務管理サーバの一構成例を示す機能ブロック図 業務Ａ用の端末装置が表示する入力インターフェイス画面の一例を示す図 業務Ａ処理部がレコードを追加した状態の第１業務フローテーブルの例を示す図 受注に割り当てられた端末装置に表示される入力インターフェイス画面の一例を示す図 受注の担当者が受注の処理を行った結果が、前記の入力インターフェイス画面に入力された画面例を示す図 受注処理部がレコードを追加した状態の第１業務フローテーブルの例を示す図 出荷指示処理部が前身レコードと自身レコードとを追加した第１業務フローテーブルの例を示す図 出荷処理部が前身レコードと自身レコードとを追加した第１業務フローテーブルの例を示す図 業務Ｂ処理部が前身レコードと自身レコードとを追加した第１業務フローテーブルの例を示す図 図１６の状態の後に新たな業務Ａが行われ、これに応じて２回の受注業務が行われた場合の第１業務フローテーブルの例を示す図 出荷指示処理部がレコードを追加した状態の第２業務フローテーブルの例を示す図 補充発注処理部がレコードを追加した状態の第２業務フローテーブルの例を示す図 業務Ｃ処理部が前身レコードと自身レコードとを追加した第２業務フローテーブルの例を示す図 将来の業務活動の結果を予測する場合に用いる、業務フローテーブルの例を示す図 金銭的管理を実行する場合に用いられる業務フローテーブルの例を示す図 第２の実施の形態にかかる業務管理サーバの構成例を示す図 オリジンテーブルのデータ構成例を示す図 オリジンテーブルのデータ構成例を示す図 グループ化に関するコンビネーションテーブルのデータ構成例を示す図 階層化に関するコンビネーションテーブルのデータ構成例を示す図 キーの範囲制御に関するコンビネーションテーブルのデータ構成例を示す図 業務フローテーブルのデータ構成例を示す図 フローコアテーブルのデータ構成例を示す図 （Ａ）は、ストックテーブルのデータ構成例を示す図、（Ｂ）は別のストックテーブルのデータ構成例を示す図 （Ａ）は拡張されたストックテーブルのデータ構成例を示す図、（Ｂ）は別の拡張されたストックテーブルのデータ構成例を示す図 バランステーブルのデータ構成例を示す図

符号の説明

８０１ … 業務管理サーバ
８０２ … 端末装置
８２０ … テーブル記憶部
５０１，５０２ … 業務フローテーブル

Claims (16)

1. 第１の業務の実行に対応する数値情報を格納する第１のフィールドと、前記第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第２のフィールドを有するレコードからなるテーブルを用い、前記第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、前記第１の業務に応じた第２の業務が完了したことを判定する、ことを特徴とする業務管理方法。
2. ある業務の実行に対応する数値情報を格納する第１のフィールドと、前記業務の次工程として行われる業務の実行に対応する数値情報を格納する第２のフィールドを有するレコードからなるテーブルを用いて、業務を管理する業務管理方法であって、
   始点タイプの業務が実行された場合には、前記第１のフィールドに数値情報を格納するが前記第２のフィールドには数値情報を格納しないレコードである自身レコードを生成してテーブルに追加するステップと、
   中間タイプの業務が実行された場合には、前記第１のフィールドに数値情報を格納せず前記第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、前記第１のフィールドに数値情報を格納するが、前記第２のフィールドには数値情報を格納していないレコードである自身レコードを生成してテーブルに追加するステップと
   を有することを特徴とする業務管理方法。
3. 終点タイプの業務が行われた場合には、前記第１のフィールドに数値情報を格納せず前記第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、前記第１のフィールドにも、前記第２のフィールドにも数値情報を格納していないレコードである自身レコードを生成してテーブルに追加するステップをさらに有することを特徴とする、請求項２に記載の業務管理方法。
4. 前記第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、業務の完了を判定するステップをさらに有することを特徴とする請求項３に記載の業務管理方法。
5. 前記テーブルは、業務フロー毎に設けられていることを特徴とする、請求項１から４のいずれかに記載の業務管理方法。
6. 前記レコードは未実行の業務であるか否かを区別するためのフィールドをさらに有することを特徴とする、請求項１から５のいずれかに記載の業務管理方法。
7. 前記レコードは第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報に対応する金銭価値を格納するフィールドをさらに有することを特徴とする、請求項１から６のいずれかに記載の業務管理方法。
8. 第１の業務の実行に対応する数値情報を格納する第１のフィールドと、前記第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第２のフィールドを有するレコードからなるテーブルを記憶し、前記第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、前記第１の業務に応じた第２の業務が完了したことを判定する、ことを特徴とする業務管理装置。
9. ある業務の実行に対応する数値情報を格納する第１のフィールドと、前記業務の次工程として行われる業務の実行に対応する数値情報を格納する第２のフィールドを有するレコードからなるテーブルを用いて、業務を管理する業務管理装置であって、
   前記テーブルを記憶する記憶手段と、
   始点タイプの業務が実行された場合には、前記第１のフィールドに数値情報を格納するが前記第２のフィールドには数値情報を格納しないレコードである自身レコードを生成してテーブルに追加し、中間タイプの業務が実行された場合には、前記第１のフィールドに数値情報を格納せず前記第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、前記第１のフィールドに数値情報を格納するが、前記第２のフィールドには数値情報を格納していないレコードである自身レコードを生成してテーブルに追加する処理手段と
   を有することを特徴とする業務管理装置。
10. 前記処理手段は、終点タイプの業務が行われた場合には、前記第１のフィールドに数値情報を格納せず前記第２のフィールドに数値情報を格納するレコードである前身レコードを生成してテーブルに追加するとともに、前記第１のフィールドにも、前記第２のフィールドにも数値情報を格納していないレコードである自身レコードを生成してテーブルに追加することを特徴とする、請求項９に記載の業務管理装置。
11. 前記処理手段は、前記第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報を比較することにより、業務の完了を判定することを特徴とする請求項１０に記載の業務管理装置。
12. 前記記憶手段は、業務フロー毎にテーブルを記憶していることを特徴とする、請求項９から１１のいずれかに記載の業務管理装置。
13. 前記記憶手段に記憶されたテーブルにおいて、各レコードは未実行の業務であるか否かを区別するためのフィールドを有することを特徴とする、請求項９から１２のいずれかに記載の業務管理装置。
14. 前記レコードは第１のフィールドに格納された数値情報と第２のフィールドに格納された数値情報に対応する金銭価値を格納するフィールドをさらに有することを特徴とする、請求項９から１３のいずれかに記載の業務管理装置。
15. 第１の業務の実行に対応する数値情報、又は前記第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第１のフィールドと、そのレコードが自身レコードか前身レコードかを識別する第２のフィールドとを有するレコードを有するテーブルを用い、前記第１のフィールドに格納された数値情報を比較することにより、前記第１の業務に応じた第２の業務が完了したことを判定する、ことを特徴とする業務管理方法。
16. 第１の業務の実行に対応する数値情報、又は前記第１の業務の次工程として行われる第２の業務の実行に対応する数値情報を格納する第１のフィールドと、そのレコードが自身レコードか前身レコードかを識別する第２のフィールドとを有するレコードを有するテーブルを記憶し、前記第１のフィールドに格納された数値情報を比較することにより、前記第１の業務に応じた第２の業務が完了したことを判定する、ことを特徴とする業務管理装置。

Images