JP6407709B2

JP6407709B2 - 業務統合管理システム

Info

Publication number: JP6407709B2
Application number: JP2014264299A
Authority: JP
Inventors: 繁夫藤本; 浩孝野口; 和哉泉川
Original assignee: SYNAPSE INNOVATION INC.
Current assignee: SYNAPSE INNOVATION INC.
Priority date: 2014-12-26
Filing date: 2014-12-26
Publication date: 2018-10-17
Anticipated expiration: 2034-12-26
Also published as: JP2016126388A

Description

本発明は、業務の統合管理を行うための業務統合管理システムに関するものである。

人事、会計、経理などの各種業務を統合して管理するために、コンピュータを用いた業務統合管理システムが提供されている（例えば、下記特許文献１参照）。この種の業務統合管理システムでは、例えばＥＲＰ（Enterprise Resource Planning）という手法に基づくプログラム（ＥＲＰパッケージ）をコンピュータが実行することにより、表示画面上で各種業務の統合管理をリアルタイムで行うことができる。

従来より、データベースがオープン化されたＥＲＰシステムが複数の提供元から提供されており、ユーザは、いずれかの提供元から購入したＥＲＰパッケージを用いてデータベース内のデータを読み書きすることにより業務の統合管理を行っている。また、ユーザによっては、ＥＲＰパッケージをカスタマイズすることにより、専用のプログラムを用いて独自の業務管理を行っている場合もある。

特許第４１５７１１２号公報

しかしながら、上記のようにしてカスタマイズされたＥＲＰパッケージは、汎用性が低いという問題があった。例えば、ＥＲＰパッケージの提供元においてＥＲＰシステムのバージョンアップがあったときなどには、ＥＲＰパッケージを変更しなければ業務管理を行うことができなくなる場合がある。また、異なる提供元から提供されるＥＲＰパッケージを利用しようとした場合には、そのＥＲＰパッケージを新たにカスタマイズしなければならないという問題がある。

本発明は、上記実情に鑑みてなされたものであり、プログラムの汎用性を向上することができる業務統合管理システムを提供することを目的とする。

本発明に係る業務統合管理システムは、データベースがオープン化されたＥＲＰシステムのデータを用いて業務の統合管理を行う業務統合管理装置と、前記ＥＲＰシステムにおいて定義された業務項目を前記業務統合管理装置において定義された業務項目に読み替えるための仮想テーブルからなるＶＩＥＷを記憶するリポジトリとを含む。前記業務統合管理装置は、前記リポジトリに記憶されている前記ＶＩＥＷを用いてプログラムを実行することにより、前記データベース内のデータを読み書きする。

このような構成によれば、仮想テーブルからなるＶＩＥＷを用いてプログラムを実行することにより、ＥＲＰシステムのデータベース内のデータを読み書きすることができる。したがって、ＥＲＰシステムのバージョンアップなどがあった場合でも、ＶＩＥＷを変更するだけで、プログラムを変更することなくデータベース内のデータを読み書きすることができる。また、ＶＩＥＷを変更するだけで、同一のプログラムを他のオープン化されたＥＲＰシステムのデータベースに適用し、同様の業務管理を行うことができる。したがって、プログラムの汎用性を向上することができる。

前記データ処理部は、開発フレームワークに基づくプログラムを実行してもよい。

このような構成によれば、開発フレームワークに基づくプログラムを実行することにより、ＥＲＰシステムのデータベース内のデータを読み書きすることができる。この場合、開発フレームワークに基づいて、より簡単な記述でプログラムを作成することができるため、プログラムの生産性を向上することができる。

前記業務統合管理装置は、当該業務統合管理装置において定義される業務項目が追加された場合に、前記ＶＩＥＷとは別のテーブルとして、追加された業務項目のテーブルを前記リポジトリに記憶してもよい。

このような構成によれば、ＥＲＰシステムにおいて定義されていない業務項目を、独自の業務項目として業務統合管理装置において定義し、追加することができる。このとき追加された業務項目は、ＶＩＥＷとは別のテーブルとしてリポジトリに記憶されるため、ＥＲＰシステムのバージョンアップなどがあった場合でも、追加された独自の業務項目についての設定を変更する必要がない。

本発明の一実施形態に係る業務統合管理システムの構成例を示したブロック図である。ＶＩＥＷを用いて業務項目を読み替える際の態様について説明するための図である。業務統合管理装置において定義される業務項目が追加された場合の態様について説明するための図である。

図１は、本発明の一実施形態に係る業務統合管理システムの構成例を示したブロック図である。この業務統合管理システムは、各種業務を統合して管理するためのシステムであり、業務統合管理装置１と、当該業務統合管理装置１に対して密結合されたＥＲＰシステム２とを備えている。ユーザは、業務統合管理装置１を操作することにより、ＥＲＰシステム２に備えられたデータベース２１内の各業務項目に対応するデータを読み書きすることができる。

業務統合管理装置１においては、ＣＰＵがリポジトリ（記憶部）１１内のデータに基づいてプログラムを実行することにより、例えば液晶表示器などの表示部に表示画面１３が表示され、当該表示画面１３上でユーザによる入力作業が行われる。プログラムを実行して業務の統合管理を行う際には、主にデータベース１４内のデータが参照される。

ＣＰＵが実行するプログラムは、開発フレームワーク１２に基づくプログラムであり、本実施形態ではＵｎｉｆａｃｅに基づいて作成されたプログラム（Ｕｎｉｆａｃｅプログラム）である。当該プログラムは、例えばリポジトリ１１内のデータ（後述するＶＩＥＷや追加テーブルなど）を参照して作成される。

開発フレームワーク１２においては、アプリケーションの中核となる制御部分が予め用意されているため、コーディングの手間を省くことができ、開発が容易である。ただし、例えばドットネットやルビーオンレイルズといった他の開発フレームワーク１２に基づくプログラムが実行されるような構成であってもよい。

ＥＲＰシステム２は、例えばＧＲＡＮＤＩＴ（登録商標）やＢｉｚ∫（登録商標）などの複数の提供元から提供されている公知のシステムであり、オープン化されたデータベース２１を備えている。ここで、オープン化されたデータベース２１とは、データベース内のテーブルレイアウトが公開されていることを意味している。

ＥＲＰシステム２のデータベース２１には、複数種類の業務項目に対応付けて、各業務項目についてのデータが記憶されている。複数種類の業務項目としては、取引先についての業務を管理するための「取引先項目」、商品情報についての業務を管理するための「商品情報項目」、売上についての業務を管理するための「売上項目」、発注についての業務を管理するための「発注項目」、請求情報についての業務を管理するための「請求情報項目」などを例示することができるが、これらに限られるものではない。

また、複数の業務項目が１つの業務項目にグループ化されていてもよい。例えば、「取引先項目」及び「商品情報項目」が他の業務項目とともに「共通項目」にグループ化され、「売上項目」が他の業務項目とともに「販売項目」にグループ化され、「発注項目」が他の業務項目とともに「調達項目」にグループ化され、「請求情報項目」が他の業務項目とともに「債権項目」にグループ化されていてもよい。この場合、グループ化された業務項目ごとにデータが記憶されてもよい。

ＥＲＰシステム２のデータベース２１に記憶されているデータは、各業務項目に対応付けて、例えば液晶表示器などの表示部に専用の表示画面２２として表示される。業務統合管理装置１を用いずに、ＥＲＰシステム２のデータベース２１に対してデータの読み書きを直接行うような場合には、ユーザが当該表示画面２２を見ながら入力作業を行うこととなる。

本実施形態では、業務統合管理装置１のリポジトリ１１に、仮想テーブルからなるＶＩＥＷが記憶されている。ＶＩＥＷは、表示画面１３に対する表示を行う際に、ＥＲＰシステム２において定義された業務項目を業務統合管理装置１において定義された業務項目に読み替える。

したがって、ユーザは、業務統合管理装置１の表示画面１３に対する入力作業を行うことにより、ＥＲＰシステム２の表示画面２２に対する入力作業を行う場合と同等の処理を行うことができる。このとき、リポジトリ１１に記憶されているＶＩＥＷを用いてプログラムが実行されることにより、ＥＲＰシステム２のデータベース２１内のデータが読み書きされる。

ＶＩＥＷは、例えば業務統合管理装置１のデータベース１４内に作成され、図１に破線で示すように、当該データベース１４からリポジトリ１１に読み込まれるようになっている。ただし、このような構成に限らず、例えばＶＩＥＷがＥＲＰシステム２のデータベース２１内に作成され、当該データベース２１からリポジトリ１１に読み込まれるような構成であってもよい。

このように、本実施形態では、仮想テーブルからなるＶＩＥＷを用いてプログラムを実行することにより、ＥＲＰシステム２のデータベース２１内のデータを読み書きすることができる。したがって、ＥＲＰシステム２のバージョンアップなどがあった場合でも、ＶＩＥＷを変更するだけで、プログラムを変更することなくデータベース２１内のデータを読み書きすることができる。また、ＶＩＥＷを変更するだけで、同一のプログラムを他のオープン化されたＥＲＰシステム２のデータベース２１に適用し、同様の業務管理を行うことができる。したがって、プログラムの汎用性を向上することができる。

図１の例では、「ＥＲＰシステムＡ」と「ＥＲＰシステムＢ」という２種類のＥＲＰシステム２が示されている。ＶＩＥＷを用いることにより、図１に実線で示すようにＥＲＰシステムＡのデータベース２１内のデータを業務統合管理装置１から読み書きすることができるが、ＶＩＥＷを変更すれば、図１に二点鎖線で示すように、同一のプログラムを用いてＥＲＰシステムＢのデータベース２１内のデータを読み書きすることができる。プログラムを他の業務統合管理装置１にコピーすれば、同一の業務統合管理装置１ではなく、異なる業務統合管理装置１において同一のプログラムを用いて業務の統合管理を行うことも可能である。

また、本実施形態では、開発フレームワーク１２に基づくプログラムを実行することにより、ＥＲＰシステム２のデータベース２１内のデータを読み書きすることができる。この場合、開発フレームワーク１２に基づいて、より簡単な記述でプログラムを作成することができるため、プログラムの生産性を向上することができる。

図２は、ＶＩＥＷを用いて業務項目を読み替える際の態様について説明するための図である。図２では、業務項目の一例として「取引先項目」を読み替える場合について説明するが、他の業務項目についても同様に読み替えを行うことができる。

業務項目には、複数の項目が含まれており、各項目に項目ＩＤ、論理名、タイプ及び桁などのデータが対応付けられている。この例では、取引先コード、取引先名及び取引先住所といった取引先についてのデータが、取引先項目に対応付けてＥＲＰシステム２のデータベース２１に記憶されている。ただし、各項目ＩＤには、論理名、タイプ及び桁に限らず、その他のデータが対応付けられていてもよい。

ＥＲＰシステムＡにおいて定義された取引先項目（ＣＵＳＴ＿Ａ）は、ＶＩＥＷ３１を用いて、業務統合管理装置１において定義された取引先項目（ＣＵＳＴ＿Ｕ）に読み替えられる。これにより、業務統合管理装置１では、当該業務統合管理装置１において定義された取引先項目（ＣＵＳＴ＿Ｕ）の項目ＩＤを用いてプログラムを実行することにより、ＥＲＰシステムＡのデータベース２１内のデータを読み書きすることができる。

ＥＲＰシステムＢにおいて定義された取引先項目（ＣＵＳＴ＿Ｂ）は、ＶＩＥＷ３１とは異なるＶＩＥＷ３２を用いて、業務統合管理装置１において定義された取引先項目（ＣＵＳＴ＿Ｕ）に読み替えられる。これにより、業務統合管理装置１では、当該業務統合管理装置１において定義された取引先項目（ＣＵＳＴ＿Ｕ）の項目ＩＤを用いてプログラムを実行することにより、ＥＲＰシステムＢのデータベース２１内のデータを読み書きすることができる。

これらの異なるＥＲＰシステム２（ＥＲＰシステムＡ及びＥＲＰシステムＢ）のデータベース２１内のデータを読み書きするための処理は、それぞれ異なるＶＩＥＷ３１，３２を用いることにより、同一のプログラムで実行することができる。すなわち、各ＥＲＰシステム２に対応するＶＩＥＷ３１，３２を用いれば、業務統合管理装置１において定義された業務項目の項目ＩＤを用いて同一のプログラムを実行することにより、各ＥＲＰシステム２のデータベース２１内のデータを読み書きすることができる。

図３は、業務統合管理装置１において定義される業務項目が追加された場合の態様について説明するための図である。図３では、図２の場合と同様に、業務項目が「取引先項目」である場合について説明するが、他の業務項目についても同様の処理を行うことができる。

本実施形態では、業務統合管理装置１において操作を行うことにより、ＥＲＰシステム２において定義されていない業務項目を新たに追加することができるようになっている。業務統合管理装置１において定義される業務項目が追加された場合には、図１に示すように、ＶＩＥＷとは別のテーブルとして、追加された業務項目のテーブル（追加テーブル）がリポジトリ１１に記憶される。追加テーブルは、例えば業務統合管理装置１のデータベース１４内に作成され、図１に破線で示すように、当該データベース１４からリポジトリ１１に読み込まれるようになっている。追加テーブルは、実テーブルであってもよいし、仮想テーブルからなる別のＶＩＥＷであってもよい。

このような新たなテーブルの追加は、例えばＥＲＰシステム２において定義されている業務項目と、業務統合管理装置１において定義されている業務項目との照合処理により実現することができる。当該照合処理は、業務統合管理装置１においてＣＰＵにより実行されてもよいし、手作業により実行されてもよい。照合処理の結果、ＥＲＰシステム２において定義されていない業務項目が業務統合管理装置１において定義されている場合には、その業務項目に対応するテーブルが追加テーブルとして作成され、リポジトリ１１に記憶される。

業務統合管理装置１においては、リポジトリ１１に記憶されているＶＩＥＷ及び追加テーブルを用いて、開発フレームワーク１２に基づくプログラムが実行されることにより、ユーザは共通の表示画面１３上で入力作業を行うことができる。すなわち、ＶＩＥＷ又は追加テーブルのいずれが用いられているかをユーザが意識することなく、ＥＲＰシステム２のデータベース２１内のデータを読み書きすることができる。

このように、本実施形態では、ＥＲＰシステム２において定義されていない業務項目を、独自の業務項目として業務統合管理装置１において定義し、追加することができる。このとき追加された業務項目は、ＶＩＥＷとは別のテーブルとしてリポジトリ１１に記憶されるため、ＥＲＰシステム２のバージョンアップなどがあった場合でも、追加された独自の業務項目についての設定を変更する必要がない。

以上の実施形態では、業務統合管理装置１にリポジトリ１１及びデータベース１４が備えられた構成について説明した。しかし、このような構成に限らず、リポジトリ１１及びデータベース１４の少なくとも一方が業務統合管理装置１とは別個に構成され、業務統合管理装置１との間でデータの送受信を行うことができるような構成であってもよい。

１業務統合管理装置
２ＥＲＰシステム
１１リポジトリ
１２開発フレームワーク
１３表示画面
１４データベース
２１データベース
２２表示画面
３１ＶＩＥＷ
３２ＶＩＥＷ

Claims

データベースがオープン化されたＥＲＰシステムのデータを用いて業務の統合管理を行う業務統合管理装置と、
前記ＥＲＰシステムにおいて定義された業務項目を前記業務統合管理装置において定義された業務項目に読み替えるための仮想テーブルからなり、前記ＥＲＰシステムのバージョンアップがあった場合に変更されるＶＩＥＷを記憶するリポジトリとを含み、
前記業務統合管理装置は、前記リポジトリに記憶されている前記ＶＩＥＷを用いてプログラムを実行することにより、前記データベース内のデータを読み書きし、
前記業務統合管理装置は、前記ＥＲＰシステムにおいて定義されていない業務項目であって、当該業務統合管理装置において定義される業務項目が追加された場合に、前記ＶＩＥＷとは別のテーブルとして、追加された業務項目のテーブルを前記リポジトリに記憶し、
前記ＥＲＰシステムのバージョンアップがあった場合でも、前記追加された業務項目についての設定は変更されないことを特徴とする業務統合管理システム。
前記業務統合管理装置は、開発フレームワークに基づくプログラムを実行することを特徴とする請求項１に記載の業務統合管理システム。
前記業務統合管理装置は、複数の前記ＥＲＰシステムのデータを用いて業務の統合管理を行い、
前記リポジトリには、複数の前記ＥＲＰシステムごとに異なる前記ＶＩＥＷが記憶され、
各ＥＲＰシステムに対応する前記ＶＩＥＷを用いて、前記業務統合管理装置において定義された業務項目に基づいて同一のプログラムを実行することにより、各ＥＲＰシステムの前記データベース内のデータを読み書きすることができることを特徴とする請求項１又は２に記載の業務統合管理システム。