(57)【要約】      （修正有）【課題】効率性とリアルタイム性に優れた、統合業務処理のためのプログラム、方法およびシステムを提供する。【解決手段】統合業務処理システムにおいて、各レコードが作業の識別子と、当該作業により影響を受ける一つ以上の資源の識別子と、当該作業による前記資源の変化量とを含む、作業の計画と実績を保存するデータベースを備える。業務処理プログラムは、当該データベースのレコードを集計することにより、現時点における各作業の実施予定時点の資源の所要量を把握し、計画処理を実行する。【選択図】図２
2020144657.tif 000002
【特許請求の範囲】
【請求項１】
業務処理を実行する業務プログラムと、
作業計画実績保存手段とを含む統合業務処理システムであって、
前記作業計画実績保存手段の各レコードが作業の識別子と、前記作業により影響を受ける一つ以上の資源の識別子と、前記作業による前記資源の変化量とを含み、
前記業務プログラムが、前記作業計画実績保存手段内のレコードを集計することにより、現時点における前記各作業の実施予定時点の前記資源の所要量を把握し、計画処理を実行する統合業務処理システム。
【請求項２】
前記作業計画実績保存手段の各レコードは挿入処理のみが行なわれ、更新処理が行なわれない、
請求項１に記載の統合業務処理システム。
【請求項３】
前記作業計画実績保存手段の各レコードは、さらに、作業実行に必要な資源の占有時間を含む請求項１、または、請求項２に記載の統合業務処理システム。
【請求項４】
さらに、作業資源展開ルール保存手段と作業資源展開ルール処理プログラムとを含み、
前記作業資源展開ルール保存手段の各レコードは適用条件と適用ルールを含み、
第一の適用ルールは、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含み、
第二の適用ルールは、前記第一の資源に必要な第二の作業と前記第二の作業の実行に必要な第三の資源の所要量を含み、
前記作業資源展開ルール処理プログラムは、前記第一の作業と前記第一の資源の所要量と前記第二の作業と前記第三の資源所要量を読み込み、最終的な資源所要量を前記作業計画実績保存手段に書き込む、
請求項１、請求項２、または、請求項３に記載の統合業務処理システム。
【請求項５】
請求項１、請求項２、または、請求項３に記載の統合業務処理システム上でコンピューターにより実行される方法であって、
適用条件をキーにして、作業・資源展開ルール保存手段から、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含む第一の適用ルールを読み込むステップと、
前記第一の資源の所要量をキーにして、作業・資源展開ルール保存手段から、第二の適用ルールを読み込むステップと、
最終的な資源所要量を前記作業計画実績保存手段に書き込むステップとを、
含む方法。
【請求項６】
請求項１、請求項２、または、請求項３に記載の統合業務処理システム上で実行されるプログラムであって、
適用条件をキーにして、作業・資源展開ルール保存手段から、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含む第一の適用ルールを読み込む命令と、
前記第一の資源の所要量をキーにして、作業・資源展開ルール保存手段から、第二の適用ルールを読み込む命令と、
最終的な資源所要量を前記作業計画実績保存手段に書き込む命令とを、
コンピューターに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は統合業務処理のためのプログラム、方法、および、システム、特に、効率性とリアルタイム性に優れたデータベースを備えたプログラム、方法、および、システムに関する。
【背景技術】
【０００２】
一般にERP（Enterprise Resource Planning）パッケージとして知られる統合業務アプリケーションが広く利用されている（たとえば、非特許文献１、特許文献１、および、特許文献２）。ERPパッケージにより、受注管理、生産管理、販売管理、在庫管理、会計等の業務に関わる処理を統合データに基づいて実現できる。
【０００３】
ERPパッケージは複数業務にまたがるデータを管理しなければならないことから、そのデータベースの構造が複雑になり、処理負荷が増大し、リアルタイム性が損なわれるという問題、および、保守性が悪化し、ソフトウェア開発コストが増加するという課題があった。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】IPS社ウェブサイト SAP ERP 製品紹介（http://www.ips.ne.jp/products/sap_erp/）
【特許文献】
【０００５】
【特許文献１】特許公開公報  特開2002-032224
【特許文献２】特許公開公報  特開平11−167590
【発明の概要】
【発明が解決しようとする課題】
【０００６】
効率性とリアルタイム性に優れた、統合業務処理のためのプログラム、方法、および、システムを提供する。
【課題を解決するための手段】
【０００７】
本願発明は、業務処理を実行する業務プログラムと、作業計画実績保存手段とを含む統合業務処理システムであって、前記作業計画実績保存手段の各レコードが作業の識別子と、前記作業により影響を受ける一つ以上の資源の識別子と、前記作業による前記資源の変化量とを含み、前記業務プログラムが、前記作業計画実績保存手段内のレコードを集計することにより、現時点における前記各作業の実施予定時点の前記資源の所要量を把握し、計画処理を実行する統合業務処理システムを提供することで上記課題を解決する。
【０００８】
また、本願発明は、前記作業計画実績保存手段の各レコードは挿入処理のみが行なわれ、更新処理が行なわれない、段落０００７に記載の統合業務処理システムを提供することで上記課題を解決する。
【０００９】
また、本願発明は、前記作業計画実績保存手段の各レコードは、さらに、作業実行に必要な資源の占有時間を含む段落０００７、または、段落０００８に記載の統合業務処理システムを提供することで上記課題を解決する。
【００１０】
また、本願発明は、さらに、作業資源展開ルール保存手段と作業資源展開ルール処理プログラムとを含み、前記作業資源展開ルール保存手段の各レコードは適用条件と適用ルールを含み、第一の適用ルールは、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含み、第二の適用ルールは、前記第一の資源に必要な第二の作業と前記第二の作業の実行に必要な第三の資源の所要量を含み、前記作業資源展開ルール処理プログラムは、前記第一の作業と前記第一の資源の所要量と前記第二の作業と前記第三の資源所要量を読み込み、最終的な資源所要量を前記作業計画実績保存手段に書き込む、段落０００７、段落０００８、または、段落０００９に記載の統合業務処理システムを提供することで上記課題を解決する。
【００１１】
また、本願発明は、段落０００７、段落０００８、または、段落０００９に記載の統合業務処理システム上でコンピューターにより実行される方法であって、適用条件をキーにして、作業・資源展開ルール保存手段から、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含む第一の適用ルールを読み込むステップと、前記第一の資源の所要量をキーにして、作業・資源展開ルール保存手段から、第二の適用ルールを読み込むステップと、最終的な資源所要量を前記作業計画実績保存手段に書き込むステップとを、含む方法を提供することで上記課題を解決する。
【００１２】
また、本願発明は、段落０００７、段落０００８、または、段落０００９に記載の統合業務処理システム上で実行されるプログラムであって、適用条件をキーにして、作業・資源展開ルール保存手段から、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含む第一の適用ルールを読み込む命令と、前記第一の資源の所要量をキーにして、作業・資源展開ルール保存手段から、第二の適用ルールを読み込む命令と、最終的な資源所要量を前記作業計画実績保存手段に書き込む命令とを、コンピューターに実行させるプログラムを提供することで上記課題を解決する。
【発明の効果】
【００１３】
効率性とリアルタイム性に優れた統合業務処理のためのプログラム、方法、および、システムが提供される。
【図面の簡単な説明】
【００１４】
【図１】本願発明に係る統合業務処理システムの実施例の機能概要図である。
【図２】本願発明に係る作業計画・実績データベースの構造の説明（UMLクラス図およびRDBMSによる設計例）である。
【図３】本願発明に係る統合業務処理システムにおいて実行される注文登録から作業計画データの生成、作業計画への資源引当、作業指示とその実績を記録するまでの処理フローの例である。
【図４】本願発明に係る作業・資源展開ルールに保存されるルール記述の具体例である。
【図５】上記図4の作業・資源展開ルールを解釈し、展開した作業計画データのイメージ図である。
【図６】本願発明に係る作業・資源展開ルール処理プログラムの処理フローの例である。
【図７】本願発明に係る、作業計画データのすべての資源要求に対して、引当可能な資源保有オブジェクトとその時間を対応づけて記録することで引当を行なうフローの例である。
【発明を実施するための形態】
【００１５】
以下に図を参照しながら本願発明の実施例について説明する。図はすべて例示である。
【００１６】
図1に、本願発明に係る統合業務処理システムの実施例の機能概要図を示す。
【００１７】
業務処理プログラム（101）は、企業組織等の業務に関連するデータを処理するためのプログラムであり、生産業務、販売業務、入出荷業務、購買業務、請求支払業務、物流業務、サービス提供業務等の機能を提供する。一つの企業組織の業務領域ごとに複数の業務処理プログラム（101-1〜101-n）が存在し、それらが共通のデータ構造のデータベースを使用することで、複数の業務を統一的な形で処理できることが望ましい。なお、図１では、一つの業務領域しか示していないが、実際には一つの企業組織内に複数の業務領域が存在し、各領域が図１と同等の構成であることが望ましい。業務処理プログラム（101）は業務領域を横断してやり取りを行なうことで相互連携することが望ましい。たとえば、生産業務の業務領域の業務処理プログラムが購買業務の業務領域の業務処理プログラムに対して、購買依頼を送信する構成であってよい。
【００１８】
作業計画・実績データベース（102）は、業務処理プログラム（101）の実行に必要な企業内の様々な作業と資源（リソース）の状態を保存するための手段であり、RDBMS（リレーショナル・データベース管理システム）等のテクノロジーを使用して実現してよい。あるいは、メモリ上のキャッシュ等のデータベース以外のテクノロジーにより実装してもよい。一つの企業組織の業務領域ごとに、複数の業務処理プログラム（101-1〜101-n）に対応する1つの作業計画・実績データ（102）が存在することが望ましい。作業計画・実績データベース（102）の詳細については後述する。
【００１９】
作業計画生成・実績記録プログラム（103）は、業務処理プログラム（101）の要求に従って、作業計画・実績データ（102）へのレコードの挿入と参照を行なうコンピューター・プログラムである。一つの企業組織の業務領域ごとに、複数の業務実行処理プログラム（101-1〜101-n）および、作業計画・実績データ（102）に対応する一つの作業計画生成・実績記録プログラム（103）が存在することが望ましい。作業計画生成・実績記録プログラム（103）の処理の詳細については後述する。
【００２０】
作業・資源展開ルール（104）は、業務処理に必要となる作業と資源の種類と量を、後述のルール記述言語等の論理表現によって汎用的に記述し、保存する手段であり、RDBMSなどのテクノロジーによって実現してよい。あるいは、メモリ上のキャッシュ等のデータベース以外のテクノロジーにより実装してもよい。作業・資源展開ルール（104）の内容は、編集プログラム（図示していない）等により、管理者等によって記述し、試験し、登録されてよい。作業・資源展開ルール（104）の作業内容、品目・設備・技能に関する記述では、品番などの識別番号によって識別するのではなく、仕様種と仕様値の組み合わせルールによって識別（パラメーター化）することで、作業・資源展開ルールの爆発的増大を防ぐことが望ましい。
【００２１】
作業・資源展開ルール処理プログラム（105）は、作業計画生成・実績記録プログラム（103）からの問い合わせに応じて、作業・資源展開ルール（104）の内容に基づいて解釈し、作業および資源計画を回答するプログラムである。企業組織内に、作業・資源展開ルール（104）と作業・資源展開ルール処理プログラム（105）は業務領域ごとに一つずつ存在し、同一業務領域内の複数の作業計画生成・実績記録プログラム（103）と連携することが望ましい。
【００２２】
上記プログラム群の説明は機能的な観点から行なったものであり、実装上は一つのプログラムによって複数の機能が提供されていてもよい。逆に、複数のプログラムが連携して一つの機能を提供していてもよい。また、上記のデータベース群が複数のデータベース実体にまたがって提供されていてもよい。さらに、一部のプログラムの機能がクラウド等の企業組織外の別のシステム上で実行されていてもよい。
【００２３】
図２-ａに、本願発明に係る作業計画・実績データ（102）の構造の例をUMLクラス図で示す。また、図２-ｂに、当該UMLクラス図に基づいたRDBMSのテーブルによる実装の例を示す。
【００２４】
作業計画・実績データ（102）は、少なくとも、注文、作業、資源移動、資源保有、および資源のクラスにおいて図２-ａに示す多重度の関係で構成される。業務処理プログラム（101-1）は、統合業務処理システムの外部から業務処理要求を受け取り、それを作業計画・実績データ（102）に記録する。注文（201）は、注文品を、販売せよ、製造せよ、請求せよなどの注文語によって、どのように処理すべきかが記録される。ここで、注文品の識別においては、商品番号や製品番号等による指定に加えて、品目に対する仕様種および仕様値の組み合わせによる指定も可能である。作業（202）は、業務処理プログラム（101）が注文内容を満足するために行なわなければならないプロセスである。プロセスとは、たとえば、注文語が「製造せよ」の場合、製造を実施する業務処理プログラム（101）が組立作業、梱包作業等を実行することになり、注文から見た作業のリスト構造は有向非循環グラフ（DAG）となる。資源型は、統合業務処理システムで使用される企業の管理対象となる経営資源のカテゴリであり、たとえば、品目、設備、スキル、勘定等である。資源（204）は、品目X、設備１、検査員スキル、個々の勘定科目等の名前を持った経営資源であり、資源型、仕様種、仕様値の組み合わせで識別されるカタログ情報である。資源のオブジェクトは、仕様種、仕様値の新しい組み合わせが必要になるときに生成される。資源保有（205）は、プロセスが移動する資源移動量から、ある時点での予定の引当可能量を導出する単位に対応するオブジェクトである。たとえば、X月X日に場所Pで製造した品目X、X月X日に購入し、場所Qに設置した設備1の3号機、普通預金の仮想口座等である。資源保有は、個品管理が不要、すなわち、名目管理で十分な場合には、現存する資源を代表する1つだけのオブジェクト（「名目の資源保有オブジェクト」という）が存在し、個品管理が必要な場合には、名目の資源保有オブジェクトと現存する個品を表す一つ以上のオブジェクトとそのリンクから成る。ここで、名目管理とは、現存する資源を代表的に管理する方式を言い、個品管理とは、現存する資源の管理単位の一つ一つを識別し、作業計画および作業実績においてそれを記録することによって、後の製品不具合の原因追及および影響範囲の特定等を行なうための管理方式である。個品の資源保有は、それが生成された日時、および、（必要な場合）寿命を持つ。個品はさらに細かい個品に分解されて引き当てられることもあり、図2-ａに示すように群ー個の階層的な再帰構造を持つ。資源移動（203）は資源保有（205）に付随する数、内容量、金額、場所、所有権等の観測項目の計測値の変化の予定または実績を記録する。作業（202）のサブタイプによって予定か実績かが決定する。
【００２５】
作業計画・実績データベース（102）は、原則的に更新処理は新レコードの挿入のみが行なわれる記録手段であり、挿入されたレコードの組は一定の保持期間満了後の削除までは、更新されることなく、維持される。作業計画・実績データベース（102）は、作業の予定の時点における企業内の様々な資源の引当可能量をその都度リアルタイムに導出するための記録手段であり、集計操作（たとえば、SQLの場合にはSUM関数）を適用することで、作業計画時における作業実施予定時における資源の引当可能量を正確に知ることができる。この本願発明に係る方式は、集計済データをRDBMSのテーブル形式に記録し別途管理する形態に比べて、特に予定変更を反映する場合のリアルタイム性に優れる。なお、今日のデータベース技術では、様々な最適化技術により集計操作の効率化が行なわれているため、集計操作を逐一行なうことによる弊害はない。
【００２６】
図３に、本願発明に係る統合業務処理システムにおいて実行される注文登録から作業計画データの生成、作業計画への資源引当、作業指示とその実績を記録するまでの処理フローの例を示す。作業計画生成・実績記録プログラム（103）は、業務処理プログラム（101）から、システム外部から渡される注文を受け（S301）、注文に形式的な問題がなければ、その注文（201）を記録し、作業・資源展開ルール処理プログラム（105）に対して、当該注文の作業計画を問い合わせる（S303）。ここで、注文とは、たとえば、特定製品の製造や特定サービスの提供等の要求である。実行計画の問い合わせを受けた作業・資源展開ルール処理プログラム（105）は、作業・資源展開ルール（103）に記載された内容に基づいて、後に記述する手順を通して注文品を実現する作業計画を展開し（600）、必要なすべての作業および資源の展開が終了すると、作業計画生成・実績記録プログラム（103）に作業計画データを回答する（S307）。作業計画生成・実績記録プログラム（103）は受け取った作業計画データに対し、作業計画・実績データベース（102）の内容に基づいて必要な資源が注文の希望納期を満たす作業開始予定時刻において引当可能であるかどうかを判断する（700）。これは、作業計画・実績データベース（102）の集計操作を行なうことで可能である。十分な資源がなく引当が不可能であった場合には、作業開始予定時刻を調整して再度引当可能であるかどうかを判断する。調整した作業開始予定時刻が計画管理期間（ホライゾン）内に収まらなかったとき、呼び出し元である業務処理プログラム（101）に引当不能である旨のエラー情報を返して処理を終了する（S310）。引当が可能な場合には、作業計画・実績データベース（102）に引当済の作業計画データを追加した後に、呼び出し元である業務処理プログラム（101）に正常終了情報を返して処理を終了する（S311）。
【００２７】
複数の業務処理プログラム（101-1〜101-n）が使用する資源が、一つの作業計画・実績データベース（102）に記録されていることにより、上述のとおり、集計処理を行なうことで、過去、現在、および将来の時点の企業組織内の資源の状況（たとえば、品目Aの在庫量、組立機1の空き時間等）を正確に知ることができる。従来技術であれば、たとえば、品目Aの在庫（新たなプロセスに引当可能な資源量）は、部品在庫テーブルの更新により管理されることが通常であるが、本願発明に係るシステムはそのような個別のテーブルは不要である。個品単位の引当可能性の管理についても図２-ａのUMLクラス図の構造によって、同様のロジックで実現できる。
【００２８】
図４に、作業・資源展開ルール（104）に保存されるルール記述の具体例を示す。作業・資源展開ルールは疑似言語を用いて記述してよい。この例では、製品Bの作業・資源展開ルールエントリと、製品Bの製造で必要となる製品Aの作業・資源展開ルールエントリを示している。各エントリでは、そのルールが適用される条件（if節）と、条件が合致したときに適用される必要作業と資源の所要量が示されている。製品Aの作業・資源展開ルールエントリでは、あらかじめ定められた仕損率から予備手配数を求め、組立プロセスにおける部品Xと部品Yのそれぞれの所要量の算出式に当てはめて（20個は空打ち用）、検査プロセスにおける不合格品の生産予定量を記述している。あわせてそれぞれのプロセスで必要となる設備や資格を持った要員の資源引当を要求している。製品Bの作業・資源展開ルールエントリでは、製品仕様の一部であるLの値によって作業内容を切り替えている。なお、投入量がマイナスになっている品目の仕様は、生産品の品目の仕様を当てはめている。
【００２９】
図５-ａに、注文の具体的数値を使用して、上記図4の作業・資源展開ルールを解釈し、展開した作業計画データのイメージ図を示す。この例では、製品Bを5個製造する場合の作業および資源を問い合わせている。説明上、仕様種および仕様値の組はデフォルト値を取るものとして省略した。資源の空き具合から、組立作業は組立区において3月2日10:43から段取り替えを行なって、部品Xを25個と部品Yを30個投入し、組立機１号機にかけて製品Aを5個製造し、11:11にはこれを梱包作業に渡し、梱包作業は梱包区において3月2日11:12から段取り替えを行なって同日の11:30に終了する予定となった。輸送作業は計画範囲外である。図５-ｂは、上記図５-ａの品目の関係だけを抜き出した図である。これは従来のMRP（資材所要量計画）でいうところの部品展開後の部品表に当たる。作業計画データは、注文ごとに生成される作業分解構造であり、かつ、作業指示用データ構造である。
【００３０】
図6は、作業・資源展開ルール処理プログラム（105）が作業計画生成・実績記録プログラム（103）から作業計画の問い合わせを受けて、作業・資源展開ルール処理を行なって展開結果の作業計画を組み立てて回答する（600）までの処理フローの例である。ここでは、製品B（仕様内容は省略）を5個製造する注文例を用いる。作業・資源展開ルール処理プログラム（105）は作業・資源展開ルール（104）に製品Bの製造方法を照会し、この注文の条件に合致するルールエントリ3が採用され、指定されたロジックが処理され、量などの変数が代入されて一つ目の作業計画データが生成される。作業計画データの中に量がマイナスとなっている製造品目（投入品目）が残っている場合は、作業・資源展開ルール処理プログラム（105）は内部的にその注文を生成し、これに基づいて作業・資源展開ルール（104）に製品Aの製造方法を照会し、この注文の条件に合致するルールエントリ１が採用され、ロジックが処理され、量などの変数が代入されて二つめの作業計画データが生成される。この作業計画データ中の量がマイナスとなっている部品Xは購買品目なので、これ以上の展開は行なわないことにして、作業計画生成・実績記録プログラム（103）に作業計画データを回答して、この処理を終了する。作業・資源展開ルール（104）中の、本注文例の条件に合致しないルールエントリ（たとえば、ルールエントリ2、4、ｎ）は適用されない。
【００３１】
図7に、上記で得られた作業計画データのすべての資源要求に対して、引当可能な資源保有オブジェクトとその時間を対応づけて記録することで引当を行なうフローの例を示す。作業計画生成・実績記録プログラム（103）は、作業・資源展開ルール処理プログラムから返された作業計画データについて、作業ステップごとに使用される資源の引当を試みる。たとえば、納期から逆方向（バックワード）に引当を行なう場合は、納期から作業計画データの所要時間（LT）を差し引いた時刻を作業開始時刻として仮設定して（S701）、すべての資源について引当可能性を調べる。これは、作業計画・実績データベース（102）の集計操作を行なうことで可能である。どれか一つの資源でも、該当時刻において十分な資源量がないと判断された場合には、作業開始予定時刻を前後に調整して、再度、上記と同様にすべての資源が引当可能であるかどうかを判断する。調整した作業開始予定時刻が計画管理期間（ホライゾン）内に収まらなかったときは、呼び出し元である業務処理プログラム（101-1）に引当不能である旨のエラー情報を返して処理を終了する（S702）。すべての作業ステップについてすべての資源が引当可能であった場合には、作業計画・実績データベース（102）に資源引当済の作業計画データを追加（S703）した後に、呼び出し元である業務処理プログラム（101-1）に対し、注文を実現する作業計画が正常に生成でき、注文を受理した旨の回答を返して、受付処理を終了する（S311）。
【００３２】
記録された作業計画データは、作業開始時刻の到来、および、部品の到着等をトリガとして作業指示画面等に表示される。また、指定された作業区において作業者等が指定された作業を実施した結果は、作業実績登録画面などを通して記録される。作業指示の作成は、指定された作業区名（たとえば、組立区および梱包区）に一致する図2-ａの作業場オブジェクトからリンクされる未実績の作業を一覧すればよい。作業実績は作業計画と一致するとは限らない。作業開始時刻が異なる、作業時間が異なる、指定された個品番号とは異なる部品を投入した、不良が発生して出来上がりの量が異なる等の要因があるからである。作業実績は、作業実績データとして記録される。図５−ｃに作業計画データに対する作業実績データの対応関係を示す。ここでは、組立作業に指定された量の部品Xおよび部品Yを投入したが、不良品が少なかったため製品Aは計画より１つ多い6個が生産され、それが梱包作業に渡されて製品Bが６個出来上がった例を表している。図2-ａに示したとおり、作業計画データと作業実績データは作業において多対多の関係として記録される（予定なし実績、未実績の予定、まとめ実績、および、分割実績がありうることを意味する）。引当可能量の集計操作においては、記録された作業実績データを優先することで、その時点から見た将来の在庫が補正される。作業実績と作業予定の差異は、注文処理の最中であっても、再計画して再引当することで、途中までの作業実績（引当可能数の増減）が反映される。図２-ａのとおり、作業実績を必要な資源保有の単位で記録でき、これは結果として納品した実績の部品表であり、保守保全の原データになる。
【００３３】
組み立て品の生産における本願発明の実施例を示してきたが、本願発明に係る統合業務処理システムは固定の工順を前提としない作業とそれに必要な資源の概念を有する多様な業務プロセスに適用可能である。たとえば、サービス業において、各スタッフ等を資源として定義し、サービスの注文内容によって異なる様々なサービス業務を作業として定義して   本願発明に係る作業・資源展開 ルールに登録しておけば、顧客からサービスの注文があった場合に、注文を受けることが可能であるかをリアルタイムで判断し、注文受付後の資源の割り当て、担当者のスケジューリング等をリアルタイムかつ自動で行なえるようになる。
【００３４】
（本願発明による技術的に顕著な効果）
本願発明により、企業組織内で使われる統合業務処理プログラムの最も重要な要素である経営資源をリアルタイムに一元管理可能となる。業務ごとに正規化を施した従来型のデータベース構造と比較して、シンプルであり性能および開発生産性向上が高い。作業計画・実績データに対する更新処理は挿入のみとなるため、変更履歴が保持されると同時に、更新競合を回避するための長期的なロックが不要であり、特に業務処理プログラムの実体数増大による並列処理に向く。作業実績データがロット単位または個体単位で記録できるので、製品の品目構成全体がロット単位または個体単位で記録できる。これは、保守部品の需要管理や部品不具合等によるリコール対象の絞り込みに有効である。また、資源の概念は部品・製品以外の概念にも拡張可能なので、製造業のみならず、サービス業等にも適用可能である。
【図１】
2020144657.tif 000003
【図２】
2020144657.tif 000004
【図３】
2020144657.tif 000005
【図４】
2020144657.tif 000006
【図５】
2020144657.tif 000007
【図６】
2020144657.tif 000008
【図７】
2020144657.tif 000009
【手続補正書】
【提出日】令和1年10月8日(2019.10.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
業務処理を実行する業務プログラムと、
作業計画実績保存手段とを含む統合業務処理システムであって、
前記作業計画実績保存手段は、UMLにおいて、
注文と、
前記注文を実施するための一つ以上の予定と実績の作業と、
前記作業により影響を受ける資源を引き当てた一つ以上の資源保有と、
前記作業による前記資源保有の変化量である資源移動とを含む構造で
表現される構造であり、
前記業務プログラムは、
前記作業計画実績保存手段内の前記各レコードをコンピューターに集計させる命令群と、
現時点における前記作業のそれぞれの実施予定時点の前記資源の所要量をコンピューターに算出させる命令群とを含む
統合業務処理システム。
【請求項２】
業務処理を実行する業務プログラムと、
作業計画実績保存手段とを含む統合業務処理システムであって、
前記作業計画実績保存手段の各レコードは、作業の識別子と、前記作業により影響を受ける一つ以上の資源の識別子と、前記作業による前記資源の変化量とを含み、
前記業務プログラムは、前記作業計画実績保存手段内の前記各レコードをコンピューターに集計させる命令群と、
現時点における前記作業のそれぞれの実施予定時点の前記資源の所要量をコンピューターに算出させる命令群とを含む
統合業務処理システム。
【請求項３】
前記作業計画実績保存手段の各レコードに対して挿入処理のみが行なわれ、更新処理が行なわれない、
請求項１、または、請求項２に記載の統合業務処理システム。
【請求項４】
前記作業計画実績保存手段の各レコードは、さらに、作業実行に必要な資源の占有時間を含む、
請求項１、請求項２、または、請求項３に記載の統合業務処理システム。
【請求項５】
さらに、作業資源展開ルール保存手段と作業資源展開ルール処理プログラムとを含み、
前記作業資源展開ルール保存手段の各レコードは適用条件と適用ルールを含み、
第一の適用ルールは、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含み、
第二の適用ルールは、前記第一の資源に必要な第二の作業と前記第二の作業の実行に必要な第三の資源の所要量を含み、
前記作業資源展開ルール処理プログラムは、前記第一の作業と前記第一の資源の所要量と前記第二の作業と前記第三の資源所要量をコンピューターに読み込ませる命令群と、最終的な資源所要量を前記作業計画実績保存手段にコンピューターに書き込ませる命令群とを含む、
請求項１、請求項２、請求項３、または、請求項４に記載の統合業務処理システム。
【請求項６】
請求項５に記載の統合業務処理システム上でコンピューターにより実行される方法であって、
適用条件をキーにして、作業資源展開ルール保存手段から、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含む第一の適用ルールを読み込むステップと、
前記第一の資源の所要量をキーにして、前記作業資源展開ルール保存手段から、第二の適用ルールを読み込むステップと、
最終的な資源所要量を前記作業計画実績保存手段に書き込むステップとを、
含む方法。
【請求項７】
請求項５に記載の統合業務処理システム上で実行されるプログラムであって、
コンピューターに、
適用条件をキーにして、作業資源展開ルール保存手段から、第一の作業と前記第一の作業の実行に必要な第一の資源の所要量を含む第一の適用ルールを読み込ませる命令群と、
前記第一の資源の所要量をキーにして、前記作業資源展開ルール保存手段から、第二の適用ルールを読み込ませる命令群と、
最終的な資源所要量を前記作業計画実績保存手段に書き込ませる命令群とを、
含むプログラム。