JP5029616B2 - 検証装置、検証方法および検証プログラム - Google Patents

Description

この発明は、複数段の業務処理からなる業務サービスについて、各業務処理におけるデータ間の検証を行うデータ検証装置およびデータ検証方法、複数段の業務処理からなる業務サービスについて、各業務処理におけるデータ間の検証方法をコンピュータに実行させるデータ検証プログラムに関する。

従来、企業内において、伝票等に記入されたデータをコンピュータに入力することにより、電子的なデータとしてコンピュータに保管して、必要に応じて出力して利用する技術が存在する。例えば、特許文献１では、各端末装置から入力された伝票に関するデータの妥当性を判断しつつ記憶して、データ処理を迅速するとともにデータの信頼性を確保する技術が開示されている。

また、従来企業内等で行われている監査業務では、監査人が企業内の取引等に関わるデータをサンプリングして、不正がないことの心証形成ができるか否かを判断基準として監査が行われていた。

特開平５−１０１０８１号公報

しかしながら、上記した従来の監査業務は、監査人の心証形成に基づいて行われるため、業務に多大な時間を要するという問題点があった。

なお、２００８年から上場企業に義務付けることを目的として、財務報告に係る内部統制の評価および監査の基準が企業会計審議会より公表され、内部統制監査を充実させるための仕組みの構築が必要とされる。

そこで、本発明は、上述した従来技術の課題を解決するためになされたものであり、従来人手で行われていた企業内の取引等に関わるデータの検証を簡易に行うことができ、また、複数のデータ間の整合性について検証することが可能なデータ検証装置、データ検証方法およびデータ検証プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、複数段の業務処理からなる業務サービスについて、各業務処理におけるデータ間の検証を行うデータ検証装置であって、業務処理単位ごとにデータを収集するデータ収集手段と、前段の業務処理を引き継いだ後段の業務処理に係るデータが前記データ収集手段により収集された場合に、前段の業務処理に係るデータと後段の業務処理係るデータとを一連のデータとして紐付けるための紐付け情報を付与して正規化するデータ正規化手段と、前記データ正規化手段により付与された前記紐付け情報とともに業務処理に係るデータをそれぞれ記憶するデータ記憶手段と、前記データ記憶手段により記憶された複数のデータの中から前記紐付け情報により紐付けられる一連のデータを読み出して、当該一連のデータ間の整合性を所定の検証条件に基づいて検証するデータ検証手段と、前記データ検証手段による検証結果を出力する検証結果出力手段と、を備えたことを特徴とする。

また、本発明は、上記の発明において、前記各業務処理におけるデータ間の検証を行う際に設定される設定項目ごとに、業務処理順序および業務処理内容からなる検証条件を記憶する検証条件記憶手段をさらに備え、前記データ検証手段は、前記検証条件記憶手段により記憶されている前記検証条件に基づいて、前記データ記憶手段により記憶されている複数のデータの中から読み出した一連のデータ間の整合性を設定項目ごとに検証することを特徴とする。

また、本発明は、上記の発明において、前記検証条件記憶手段は、各業務処理におけるデータ内容について検証を行う際の検証項目ごとに、検証対象となるデータを絞り込むための絞込み情報および検証内容からなる個別検証条件をさらに記憶し、前記データ検証手段は、前記検証条件記憶手段により記憶されている個別検証条件に基づいて、前記データ記憶手段により記憶されている複数のデータから読み出した前記一連のデータ群を構成する単一データの内容をそれぞれ検証することを特徴とする。

また、本発明は、上記の発明において、前記データ正規化手段は、前記データ収集手段により収集された複数のデータをそれぞれ正規化する際に、各業務処理単位に共通するデータ項目で統一した形式にそれぞれ変換し、前記データ検証手段は、前記データ記憶手段により記憶された複数のデータの中から一定期間内に記憶された複数のデータを前記データ項目ごとに読み出し、当該読み出された複数のデータに関する整合性を所定の検証条件に基づいて検証することを特徴とする。

また、本発明は、上記の発明において、前記データ収集手段は、前記一連のデータ間の検証が行われるデータのみを収集することを特徴とする。

また、本発明は、上記の発明において、前記検証条件記憶手段は、前記検証項目および前記絞込み情報に対応付けて、業務処理内容の特性ごとに設定した検証の必要性の尺度を示す尺度情報をさらに記憶し、前記検証条件記憶手段により記憶された前記尺度情報に基づいて、前記データ記憶手段により記憶された複数のデータの中からデータを抽出するデータ抽出手段をさらに備え、前記データ検証手段は、前記検証条件記憶手段により記憶された個別検証条件に基づいて、前記データ抽出手段により抽出されたデータの内容をそれぞれ検証することを特徴とする。

また、本発明は、複数段の業務処理からなる業務サービスについて、各業務処理におけるデータ間の検証を行うデータ検証方法であって、業務処理単位ごとにデータを収集するデータ収集工程と、前段の業務処理を引き継いだ後段の業務処理に係るデータを前記データ収集工程により収集した場合に、前段の業務処理に係るデータと後段の業務処理係るデータとを一連のデータとして紐付けるための紐付け情報を付与して正規化するデータ正規化工程と、前記データ正規化工程により付与された前記紐付け情報とともに業務処理に係るデータを記憶部にそれぞれ記憶するデータ記憶工程と、前記データ記憶工程により記憶部に記憶された複数のデータの中から前記紐付け情報により紐付けられる一連のデータを読み出して、当該一連のデータ間の整合性を所定の検証条件に基づいて検証するデータ検証工程と、前記データ検証工程による検証結果を出力する検証結果出力工程と、を含んだことを特徴とする。

また、本発明は、上記の発明において、前記各業務処理におけるデータ間の検証を行う際に設定される設定項目ごとに、業務処理順序および業務処理内容からなる検証条件を記憶部に記憶する検証条件記憶工程をさらに含み、前記データ検証工程は、前記検証条件記憶工程により記憶部に記憶されている前記検証条件に基づいて、前記データ記憶工程により記憶部に記憶されている複数のデータの中から読み出した一連のデータ間の整合性を設定項目ごとに検証することを特徴とする。

また、本発明は、上記の発明において、前記検証条件記憶工程は、各業務処理におけるデータ内容について検証を行う際の検証項目ごとに、検証対象となるデータを絞り込むための絞込み情報および検証内容からなる個別検証条件をさらに記憶部に記憶し、前記データ検証工程は、前記検証条件記憶工程により記憶部に記憶されている個別検証条件に基づいて、前記データ記憶工程により記憶部に記憶されている複数のデータから読み出した前記一連のデータ群を構成する単一データの内容をそれぞれ検証することを特徴とする。

また、本発明は、上記の発明において、前記データ正規化工程は、前記データ収集工程により収集された複数のデータをそれぞれ正規化する際に、各業務処理単位に共通するデータ項目で統一した形式にそれぞれ変換し、前記データ検証工程は、前記データ記憶工程により記憶部に記憶されている複数のデータの中から一定期間内に記憶された複数のデータを前記データ項目ごとに読み出して、複数のデータに関する整合性を所定の検証条件に基づいて検証することを特徴とする。

また、本発明は、上記の発明において、前記データ収集工程は、前記一連のデータ間の検証が行われるデータのみを収集することを特徴とする。

また、本発明は、上記の発明において、前記データ記憶工程は、単一の業務処理に係るデータが前記データ収集工程により収集された場合に、当該単一の業務処理に係るデータを記憶部に記憶し、前記データ検証工程は、前記検証条件記憶工程により記憶部に記憶されている前記個別検証条件に基づいて、前記データ記憶工程により記憶部に記憶されている単一の業務処理に係るデータの内容を検証することを特徴とする。

また、本発明は、上記の発明において、前記検証条件記憶工程は、前記検証項目および前記絞込み情報に対応付けて、業務処理内容の特性ごとに設定した検証の必要性の尺度を示す尺度情報をさらに記憶部に記憶し、前記検証条件記憶工程により記憶部に記憶されている前記尺度情報に基づいて、前記データ記憶工程により記憶部に記憶されている複数のデータの中からデータを抽出するデータ抽出工程をさらに含み、前記データ検証工程は、前記検証条件記憶工程により記憶部に記憶されている個別検証条件に基づいて、前記データ抽出工程により抽出されたデータの内容をそれぞれ検証することを特徴とする。

また、本発明は、複数段の業務処理からなる業務サービスについて、各業務処理におけるデータ間の検証を行う方法をコンピュータに実行させるデータ検証プログラムであって、業務処理単位ごとにデータを収集するデータ収集手順と、前段の業務処理を引き継いだ後段の業務処理に係るデータを前記データ収集手順により収集した場合に、前段の業務処理に係るデータと後段の業務処理係るデータとを一連のデータとして紐付けるための紐付け情報を付与して正規化するデータ正規化手順と、前記データ正規化手順により付与された前記紐付け情報とともに業務処理に係るデータを記憶部にそれぞれ記憶するデータ記憶手順と、前記データ記憶手順により記憶部に記憶された複数のデータの中から前記紐付け情報により紐付けられる一連のデータを読み出して、当該一連のデータ間の整合性を所定の検証条件に基づいて検証するデータ検証手順と、前記データ検証手順による検証結果を出力する検証結果出力手順と、をコンピュータに実行させることを特徴とする。

また、本発明は、上記の発明において、前記各業務処理におけるデータ間の検証を行う際に設定される設定項目ごとに、業務処理順序および業務処理内容からなる検証条件を記憶部に記憶する検証条件記憶手順をさらにコンピュータに実行させ、前記データ検証手順は、前記検証条件記憶手順により記憶部に記憶されている前記検証条件に基づいて、前記データ記憶手順により記憶部に記憶されている複数のデータの中から読み出した一連のデータ間の整合性を設定項目ごとに検証することを特徴とする。

また、本発明は、上記の発明において、前記検証条件記憶手順は、各業務処理におけるデータ内容について検証を行う際の検証項目ごとに、検証対象となるデータを絞り込むための絞込み情報および検証内容からなる個別検証条件をさらに記憶部に記憶し、前記データ検証手順は、前記検証条件記憶手順により記憶部に記憶されている個別検証条件に基づいて、前記データ記憶手順により記憶部に記憶されている複数のデータから読み出した前記一連のデータ群を構成する単一データの内容をそれぞれ検証することを特徴とする。

また、本発明は、上記の発明において、前記データ正規化手順は、前記データ収集手順により収集された複数のデータをそれぞれ正規化する際に、各業務処理単位に共通するデータ項目で統一した形式にそれぞれ変換し、前記データ検証手順は、前記データ記憶手順により記憶部に記憶されている複数のデータの中から一定期間内に記憶された複数のデータを前記データ項目ごとに読み出して、複数のデータに関する整合性を所定の検証条件に基づいて検証することを特徴とする。

また、本発明は、上記の発明において、前記データ収集手順は、前記一連のデータ間の検証が行われるデータのみを収集することを特徴とする。

また、本発明は、上記の発明において、前記データ記憶手順は、単一の業務処理に係るデータが前記データ収集手順により収集された場合に、当該単一の業務処理に係るデータを記憶部に記憶し、前記データ検証手順は、前記検証条件記憶手順により記憶部に記憶されている前記個別検証条件に基づいて、前記データ記憶手順により記憶部に記憶された単一の業務処理に係るデータの内容を検証することを特徴とする。

また、本発明は、上記の発明において、前記検証条件記憶手順は、前記検証項目および前記絞込み情報に対応付けて、業務処理内容の特性ごとに設定した検証の必要性の尺度を示す尺度情報をさらに記憶部に記憶し、前記検証条件記憶手順により記憶部に記憶されている前記尺度情報に基づいて、前記データ記憶手順により記憶部に記憶されている複数のデータの中からデータを抽出するデータ抽出手順をさらにコンピュータに実行させ、前記データ検証手順は、前記検証条件記憶手順により記憶部に記憶されている個別検証条件に基づいて、前記データ抽出手順により抽出されたデータの内容をそれぞれ検証することを特徴とする。

本発明によれば、業務処理単位（例えば、受注や出荷など）ごとにデータを収集し、前段の業務処理を引き継いだ後段の業務処理に係るデータが収集された場合に、前段の業務処理に係るデータと後段の業務処理係るデータとを一連のデータ（例えば、受注データ、出荷データおよび売上データからなる一連のデータ）として紐付けるための紐付け情報（例えば、紐付けキーやリンクキーなどの情報）を付与して正規化して、紐付け情報とともに業務処理に係るデータをそれぞれ記憶しておき、記憶された複数のデータの中から紐付け情報により紐付けられる一連のデータを読み出し、一連のデータ間の整合性を所定の検証条件に基づいて検証して検証結果を出力する、すなわち、一連のデータを紐付けるための情報に基づいて、業務処理が引き継がれる一連のデータを記憶されたデータの中から抜き出すとともに、業務処理順序および業務処理内容からなる所定の検証条件（例えば、受注、出荷、売上の順にデータが計上されているか否かなどの条件）に基づいて、一連のデータの整合性を検証するので、従来人手で行われていた企業内の取引等に関わるデータの検証を簡易に行うことができ、また、複数のデータ間の整合性について検証することが可能である。

また、本発明によれば、各種業務における業務処理単位ごとに収集された複数のデータをそれぞれ正規化する際に、各業務処理単位に共通するデータ項目（例えば、取引日や取引先、出張先などの業務処理に関する項目）で統一した形式にそれぞれ変換し、記憶された複数のデータの中から一定期間内に記憶された複数のデータをデータ項目ごとに読み出し、読み出された複数のデータに関する整合性を所定の検証条件に基づいて検証するので、例えば、同一取引先との取引件数など、一定期間の集計値について検証する必要がある場合などに、データ項目ごとに一定期間内に行われた業務処理に関わるデータを簡単に読み出すことができ、複数のデータに関する整合性を効率的に検証することが可能である。

また、本発明によれば、一連のデータ間の整合性の検証が行われるデータのみを収集するので、仮に、明細データ間の検証に関係のない“画面起動”や“起票者”、“起票端末名”などからなる業務操作記録データを収集している場合に必要なデータの絞込みを行なう必要がなく、複数の明細データ間の検証を効率的に実行することが可能である。

また、本発明によれば、各業務処理におけるデータの検証を行うための検証項目ごとに、検証対象となるデータを絞り込むための絞込み情報および検証内容からなる個別検証条件を記憶しておき、後段の業務処理に引き継がれることのなく業務が完結する単一の業務処理に係るデータの内容や、業務処理が引き継がれる一連のデータの内容について、個別検証条件に基づいてそれぞれ検証するので、一連のデータ間の整合性のみならず、一連のデータを構成する各データや単独で業務処理が完結するデータ（例えば、旅費）の具体的な内容についても検証することが可能である。

また、本発明によれば、データの検証項目および絞込み情報に対応付けて、隠蔽性、不特定性およびリスクの程度を示す情報を記憶しておき、記憶された隠蔽性、不特定性およびリスクの程度を示す情報（例えば、リスクについて「低」、「中」、「高」といった程度を示す情報）に応じて、記憶された複数のデータの中からデータを抽出するとともに、個別検証条件に基づいて抽出されたデータの内容をそれぞれ検証するので、データ内容に問題がある蓋然性の高いデータについて効率的に検証を行うことが可能である。

図１は、実施例１に係るデータ検証装置の概要および特徴を説明するための図である。 図２は、実施例１に係る明細データの収集および正規化の流れを示す概念図である。 図３は、実施例１に係る検証辞書マスタの構成例を示す図である。 図４は、実施例１に係る複数の明細データ間の検証例を示す図である。 図５は、実施例１に係るデータ検証装置の構成を示すブロック図である。 図６は、実施例１に係る確定業務明細データＤＢに記憶される情報の構成例を示す図である。 図７は、実施例１に係る検証結果の出力例を示す図である。 図８は、実施例１に係る明細データの収集および正規化処理の流れを示すフローチャートである。 図９は、実施例１に係る検証処理の流れを示すフローチャートである。 図１０は、実施例２に係る検証辞書マスタの構成例を示す図である。 図１１は、実施例２に係る確定業務明細データＤＢに記憶される情報の構成例を示す図である。 図１２は、実施例２に係る検証処理の流れを示すフローチャートである。 図１３は、実施例３に係る明細データのフォーマット変換例を示す図である。 図１４は、実施例３に係る確定業務明細データＤＢに記憶される情報の構成例を示す図である。 図１５は、実施例３に係る明細データの収集および正規化処理の流れを示すフローチャートである。 図１６は、データ検証プログラムを実行するコンピュータを示す図である。

符号の説明

１０ 販売系システム
１１ 生産系システム
１２ 予算編成システム
１３ 調達系システム
１４ 会計系システム
２０ データ検証装置
２１ 通信制御Ｉ／Ｆ部
２２ 入力部
２３ 出力部
２４ 記憶部
２４ａ 確定業務明細データＤＢ
２４ｂ 業務手続記録明細データＤＢ
２５ 制御部
２５ａ データ収集処理部
２５ｂ データ正規化処理部
２５ｃ データ検証処理部
３０ コンピュータ
３１ 通信制御Ｉ／Ｆ部
３２ 入力部
３３ 出力部
３４ ＨＤＤ（Hard Disk Drive）
３５ ＲＡＭ（Random Access Memory）
３６ ＲＯＭ（Read Only Memory）
３７ ＣＰＵ（Central Processing Unit）
４０ バス

以下に添付図面を参照して、本発明に係るデータ検証装置、データ検証方法およびデータ検証プログラムの実施例を詳細に説明する。なお、以下では、本実施例で用いる主要な用語（用語の説明）を説明して、本発明に係るデータ検証装置を実施例１として説明した後に、本発明に含まれる他の実施例を説明する。

［用語の説明］
まず、本実施例で用いる主要な用語を説明する。本実施例で用いる「ＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）」とは、ビジネスプロセスの構成単位に合わせてソフトウェア部門や機能を柔軟に連携させるためのシステムアーキテクチャであるＳＯＡ（Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）に基づいた高機能な処理プログラムのことであり、仮想的なメッセージバスであるＥＳＢを経由させて、各業務システム（例えば、販売系システムや生産系システムなど）間でデータがやり取りされるようにシステムを構成することができる。

また、本実施例で用いる「ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、文書やデータの意味や構造を記述するための一つであり、利用者が自由にタグを定義でき、文書中の文字列に意味付けができる言語構造を持っており、プログラムで自在にＸＭＬデータを情報処理できるというメリットがある。

［データ検証装置の概要および特徴（実施例１）］
まず、図１を用いて、実施例１に係るデータ検証装置の概要および特徴を説明する。図１は、実施例１に係るデータ検証装置の概要および特徴を説明するための図である。

実施例１に係るデータ検証装置は、受注処理を行った後、出荷処理を行うなどの複数段の業務処理からなる業務サービスについて、各業務処理におけるデータ間の検証を行うことを概要とするが、従来人手で行われていた企業内の取引等に関わるデータの検証を簡易に行うことができ、また、複数のデータ間の整合性について検証することが可能である点に主たる特徴がある。

この主たる特徴について具体的に説明すると、図１に示すように、実施例１に係るデータ検証装置は、販売系システム、生産系システム、予算編成システム、調達系システムおよび会計系システムと通信可能に接続される。また、実施例１に係るデータ検証装置は、確定業務明細データ（例えば、会計システムに計上される会計データや、各システムに計上される業務データなど）を記憶するための確定業務明細データＤＢと、業務手続記録明細データ（例えば、受注の業務処理として行われる受注入力処理や受注可決処理に関する業務手続データ）を記憶するための業務手続記録明細データＤＢを備える。

そして、各システムにおいて各種業務処理が発生すると、実施例１に係るデータ検証装置は、ＥＳＢを介して、業務処理単位（例えば、受注や出荷などの処理単位）ごとに各種明細データを収集するとともに（図１の（１）参照）、収集した各種明細データを正規化して（図１の（２）参照）、確定業務明細データＤＢまたは業務手続記録明細データＤＢにそれぞれ登録する。

具体的に説明すると、図２に例示するように、例えば、受注の業務処理に関する受注入力指示を管理者などから受け付けた販売システムにおいて、伝票番号を採番した明細データがデータベースに登録されると（図２の（１）参照）、実施例１に係るデータ検証装置は、ＥＳＢ内を流れる受注入力処理の明細データを収集するとともに、明細データから伝票番号を取得する（図２の（２）参照）。

そして、実施例１に係るデータ検証装置は、収集した明細データに記載されている業務処理名に基づいてデータの登録先を判定して（図２の（３）参照）、明細データから取得した伝票番号を紐付けキーとして付与して正規化した明細データをＤＢに登録する（図２の（４）参照）。例えば、図２に示すように、明細データの業務処理名が「受注入力」である場合には、業務手続処理として業務手続記録明細データＤＢに登録すべきものであると判定し、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢに登録する。

受注入力処理に続いて、受注入力処理の明細データと同一の伝票番号を指定した受注可決指示を管理者などから受け付けた販売システムにより受注可決処理が実行されると、実施例１に係るデータ検証装置は、販売システムにおいて受注入力処理が実行された場合と同様に、ＥＳＢ内を流れる受注可決処理の明細データを収集するとともに、明細データから伝票番号を取得する。そして、収集した明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与して正規化した明細データをＤＢに登録する。

例えば、図２に示すように、実施例１に係るデータ検証装置は、明細データの業務処理名が「受注可決」である場合には、業務手続処理として業務手続記録明細データＤＢに登録すべきものであると判定し、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢに登録する。

また、実施例１に係るデータ検証装置は、「受注可決」により受注の業務処理が確定することから、受注可決処理にまで至る明細データを確定業務明細データＤＢにも登録すべきものと判定し、伝票番号を紐付けキーとして付与して正規化した明細データを確定業務明細データＤＢに登録する。

受注処理に続いて、受注処理（受注入力処理および受注可決処理）の明細データと同一の伝票番号を指定した出荷処理に関する出荷指示を管理者などから受け付けた販売システムにおいて（図２の（５）参照）、受注処理の明細データと同一の伝票番号を採番した明細データがデータベースに登録されると、受注処理において上記で説明したのと同様に、実施例１に係るデータ検証装置は、ＥＳＢ内を流れる出荷指示処理の明細データを収集するとともに明細データから伝票番号を取得して、収集した出荷指示処理の明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与して正規化した明細データをＤＢに登録する。例えば、明細データの業務処理名が「出荷指示」である場合には、業務手続処理として業務手続記録明細データＤＢに登録すべきものであると判定し、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢに登録する。

出荷指示処理に続いて、出荷指示処理の明細データと同一の伝票番号を指定した出荷可決指示を管理者などから受け付けた販売システムにより出荷可決処理が実行されると、実施例１に係るデータ検証装置は、受注処理において上記で説明したのと同様に、ＥＳＢ内を流れる受注可決処理の明細データを収集するとともに明細データから伝票番号を取得して、収集した出荷可決処理の明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与して正規化した明細データを登録する。

例えば、実施例１に係るデータ検証装置は、明細データの業務処理名が「出荷可決」である場合には、業務手続処理として業務手続記録明細データＤＢに登録すべきものであると判定するとともに、「出荷可決」により出荷の業務処理が確定することから、出荷可決処理にまで至る明細データを確定業務明細データＤＢにも登録すべきものと判定して、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢおよび確定業務明細データＤＢにそれぞれ登録する（図２の（６）参照）。

上述してきたように、実施例１に係るデータ検証装置は、受注から集荷に至る業務処理の明細データについて、伝票番号を紐付けキーとして利用することで一連データとして各データベースに登録することができる。なお、図には示していないが、“画面起動”や“起票者”、“起票端末名”などからなる業務操作記録データも合わせて収集される。

そして、実施例１に係るデータ検証装置は、例えば、管理者などから検証処理の実行指示を受け付けると、内部的に備える検証辞書マスタ（図３参照）に基づいて、確定業務明細データＤＢに登録された複数の明細データ間の整合性を検証する（図１の（３）参照）。

具体的には、実施例１に係るデータ検証装置は、まず、確定業務明細データＤＢから紐付けキーによって紐付けられる一連のデータを読み込む。次に、検証辞書マスタの検証プロセス設定マスタ（図３参照）に基づいて、確定業務明細データＤＢから読み込んだ一連のデータを並び替える。例えば、勘定科目「売上」として計上された「受注」の各明細データ、「出荷」の各明細データおよび「債権」の各明細データで構成される一連のデータについて検証する場合には、検証プロセス設定マスタのチェック項目「科目」の「売上」について設定された処理順（例えば、条件が「受注」である場合には処理順「１」、条件が「出荷」である場合には処理順「２」、条件が「債権」である場合には処理順「３」など）に応じて、読み込んだ一連のデータを「受注」、「出荷」、「債権」の順に並び替える。

一連のデータを並び替えた後、実施例１にデータ検証装置は、並び替えられた一連のデータ間の整合性に問題があるか否か検証する。例えば、図４に例示するように、処理日時（例えば、伝票日付）を降順にそれぞれ比較して処理日時の新旧の矛盾（例えば、「債権」の処理日時が「出荷」の処理日時より新しい日付である場合には矛盾）や一連のデータからの業務処理の一部欠落（例えば、出荷の「業務処理」に関するデータの欠落）、各データ間のデータ要素の不一致（例えば、商品名や取引先の不一致）などを検証する。

検証した結果、一連のデータ間の整合性に問題がある場合には、実施例１に係るデータ検証装置は、整合性に問題のあるデータについて、確定業務明細データＤＢにチェック情報を書き込む。そして、読み込み可能な一連のデータがある場合（例えば、最終的なデータの計上が終了している一連のデータがある場合）には、引き続き確定業務明細データＤＢから読み込み可能な一連のデータを読み出して、上記で説明したのと同様に一連のデータの整合性に問題があるか否か検証する。

なお、実施例１のデータ検証装置は、複数の明細データ間の整合性を検証する場合に限られるものではなく、検証辞書マスタの検証条件設定マスタ（図３参照）に基づいて、一連のデータを構成する各明細データ（例えば、「受注」や「出荷」など業務処理に関する各明細データ）の内容について整合性を検証するようにしてもよい。仮に、読み込んだ明細データの中に勘定科目が「旅費」である明細データがある場合には金額をチェックして、例えば、１０万円以上であれば整合性に問題があるデータとして、確定業務明細データＤＢにチェック情報を書き込む。

そして、実施例１に係るデータ検証装置は、確定業務明細データＤＢに登録された複数の明細データ間の整合性に関する検証処理を終えると、確定業務明細データＤＢからチェック情報が書き込まれた明細データを読み込んで検証結果を出力する。

このようなことから、実施例１にかかるデータ検証装置は、従来人手で行われていた企業内の取引等に関わるデータの検証を簡易に行うことができ、また、複数のデータ間の整合性について検証することが可能である。

［データ検証装置の構成（実施例１）］
次に、図５を用いて、実施例１に係るデータ検証装置の構成を説明する。図５は、実施例１に係るデータ検証装置の構成を示すブロック図である。同図に示すように、実施例１に係るデータ検証装置２０は、販売系システム、生産系システム、予算編成システム、調達系システムおよび会計系システムと通信可能に接続される。また、実施例１に係るデータ検証装置２０は、通信制御Ｉ／Ｆ部２１と、入力部２２と、出力部２３と、記憶部２４と、制御部２５とから構成される。

このうち、通信制御Ｉ／Ｆ部２１は、各システムとの間でやり取りする明細データに関する通信を制御する。入力部２２は、データ制御装置２０の管理者などから各種の情報の入力や処理実行指示の入力を受け付け、キーボードやマウス、マイクなどを備えて構成され、例えば、複数の明細データ間に関する整合性の検証処理実行指示などを受け付けて入力する。また、出力部２３は、各種の情報を出力し、モニタ（若しくはディスプレイ、タッチパネル）やスピーカを備えて構成され、例えば、複数の明細データ間に関する整合性の検証処理結果などを表示出力する。

記憶部２４は、制御部２５による各種処理に必要なデータおよびプログラムを記憶する記憶部であり、特に本発明に密接に関連するものとしては、検証辞書マスタ２４ａ、確定業務明細データＤＢ２４ｂおよび業務手続記録明細データＤＢ２４ｃを備える。

このうち、検証辞書マスタ２４ａは、後述するデータ検証処理部２５ｃによる複数の明細データ間の整合性等の検証に用いるためのデータであり、検証条件設定マスタおよび検証プロセス設定マスタから構成される。

具体的には、図３に例示するように、検証条件設定マスタは、検証処理の条件項目（例えば、「勘定科目」や「取引先」など）に対応付けて、データを絞り込むためのキー値（例えば、キー値１「旅費」やキー値２「預金」）と、チェック対象（例えば、「金額」）と、検証内容（例えば、勘定科目の旅費のチェック対象である金額が１０万円を超えているか否かなど）とを記憶して構成される。また、検証プロセス設定マスタは、検証処理を実行するために設定されたチェック項目（例えば、「科目」や「取引先」）ごとに、業務処理の順序である処理順および業務内容である条件を記憶して構成される。

なお、検証辞書マスタの検証条件設定マスタおよび検証プロセス設定マスタ内のデータは、ユーザにより適宜設定可能である。

また、確定業務明細データＤＢ２４ｂは、確定業務明細データ（例えば、会計システムに計上される会計データや、各システムに計上される業務データなど）を記憶するためのデータベースであり、具体的には、図６に例示するように、「伝票日付」、「伝票番号」、「業務部門」、「負担部門」、「取引先」、「出張先」、「起票者」、「認証日」、「承認者」、「業務」、「オーダ」、「金額」、「借方科目」、「貸方科目」、「紐付けキー」および「チェック情報」などをそれぞれ対応づけて記憶して構成される。

また、業務手続記録明細データＤＢ２４ｃは、業務手続記録明細データ（例えば、受注の業務処理として行われる受注入力処理や受注可決処理に関する業務手続データ）を記憶するためのデータベースである（図２参照）。

制御部２５は、所定の制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する処理部であり、特に本発明に密接に関連するものとしては、データ収集処理部２５ａ、データ正規化処理部２５ｂおよびデータ検証処理部２５ｃを備える。

このうち、データ収集処理部２５ａは、ＥＳＢを介して、業務処理単位（例えば、受注や出荷などの処理単位）ごとに各種明細データを収集する処理部である。具体的には、例えば、受注の業務処理に関する受注入力指示を管理者などから受け付けた販売システムにおいて、伝票番号を採番した明細データがデータベースに登録されると、ＥＳＢ内を流れる受注入力処理の明細データを収集するとともに、明細データから伝票番号を取得する（図２の（１）および（２）等参照）。

また、データ収集処理部２５ａは、受注入力処理に続いて、受注入力処理の明細データと同一の伝票番号を指定した受注可決指示を管理者などから受け付けた販売システムにより受注可決処理が実行されると、ＥＳＢ内を流れる受注可決処理の明細データを収集するとともに、明細データから伝票番号を取得する。同様にして、受注処理の明細データと同一の伝票番号を指定した出荷指示処理や出荷可決指示処理の明細データをＥＳＢからそれぞれ収集するとともに、各明細データから伝票番号を取得する。なお、後述するデータ検証処理部２５ｃにより実行される複数の明細データ間の検証に利用されることのない“画面起動”や“起票者”、“起票端末名”などからなる業務操作記録データも合わせて収集される。

データ正規化処理部２５ｂは、データ収集処理部２５ａにより収集された各種明細データを正規化する処理部である。具体的には、データ収集処理部２５ａにより収集された明細データに記載されている業務処理名に基づいて明細データの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与して正規化した明細データをＤＢ登録する（図２の（３）および（４）等参照）。例えば、図２に示すように、明細データの業務処理名が「受注入力」である場合には、業務手続処理として業務手続記録明細データＤＢ２４ｃに登録すべきものであると判定し、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢ２５ｂに登録する。

また、データ正規化処理部２５ｂは、データ収集処理部２５ａにより、受注入力処理の明細データと同一の伝票番号が指定された受注可決処理の明細データがＥＳＢ内から収集されると、業務手続処理として業務手続記録明細データＤＢ２４ｃに登録すべきものであると判定し、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢ２４ｃに登録するとともに、「受注可決」により受注の業務処理が確定することから、受注可決処理にまで至る明細データを確定業務明細データＤＢ２４ｂにも登録すべきものと判定し、伝票番号を紐付けキーとして付与して正規化した明細データを確定業務明細データＤＢ２４ｂに登録する。

同様にして、データ正規化処理部２５ｂは、受注処理（受注入力処理および受注可決処理）の明細データと同一の伝票番号が指定された出荷処理（出荷指示実行処理および出荷可決実行処理）の各明細データがＥＳＢ内から収集されると、各明細データから伝票番号を取得するとともに、各明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与して正規化した明細データを確定業務明細データＤＢ２４ｂや業務手続記録明細データＤＢ２４ｃにそれぞれ登録する。

なお、上述したデータ収集処理部２５ａおよびデータ正規化処理部２５ｂによる処理は、データ検証装置２０の電源投入時において繰り返し実行される。また、データ正規化処理部２５ｂは、データ収集処理部２５ａにより収集された明細データに記載されている業務処理名に基づいて、「業務」の項目に業務処理名を自動的に登録するようにしてもよい。

データ検証処理部２５ｃは、例えば、管理者などから検証処理の実行指示を受け付けると、記憶部２４から読み出した検証辞書マスタ（図３参照）に基づいて、確定業務明細データＤＢ２４ｂに登録された複数の明細データ間の整合性等を検証する処理部である。

検証処理について具体的に説明すると、データ検証処理部２５ｃは、まず、確定業務明細データＤＢ２４ｂから紐付けキーによって紐付けられる一連のデータを読み込む。次に、検証辞書マスタの検証プロセス設定マスタ（図３参照）に基づいて、確定業務明細データＤＢ２４ｂから読み込んだ一連のデータを並び替える。例えば、勘定科目「売上」として計上された「受注」の各明細データ、「出荷」の各明細データおよび「債権」の各明細データで構成される一連のデータについて検証する場合には、検証プロセス設定マスタのチェック項目「科目」の「売上」について設定された処理順（例えば、条件が「受注」である場合には処理順「１」、条件が「出荷」である場合には処理順「２」、条件が「債権」である場合には処理順「３」など）に応じて、読み込んだ一連のデータを「受注」、「出荷」、「債権」の順に並び替える。

一連のデータを並び替えた後、データ検証処理部２５ｃは、並び替えられた一連のデータ間の整合性に問題があるか否か検証する。例えば、処理日時（例えば、伝票日付）を降順にそれぞれ比較して処理日時の新旧の矛盾（例えば、「債権」の処理日時が「出荷」の処理日時より新しい日付である場合には矛盾）や一連のデータからの業務処理の一部欠落（例えば、出荷の「業務処理」に関するデータの欠落）、各データ間のデータ要素の不一致（例えば、商品名や取引先の不一致）などを検証する（図４参照）。

検証した結果、一連のデータ間の整合性に問題がある場合には、データ検証処理部２５ｃは、整合性に問題のあるデータについて、確定業務明細データＤＢ２４ｂにチェック情報を書き込む。そして、読み込み可能な一連のデータがある場合（例えば、最終的なデータの計上が終了している一連のデータがある場合）には、引き続き確定業務明細データＤＢ２４ｂから読み込み可能な一連のデータを読み出して、上記で説明したのと同様に一連のデータの整合性に問題があるか否か検証する。

そして、データ検証処理部２５ｃは、確定業務明細データＤＢ２４ｂに登録された複数の明細データ間の整合性に関する検証処理を終えると、確定業務明細データＤＢ２４ｂからチェック情報が書き込まれた明細データを読み込んで、例えば、図７に例示するように、伝票日時である処理日時、具体的なチェック内容および伝票番号からなる検証結果を出力する。

なお、データ検証処理部２５ｃは、複数の明細データ間の整合性を検証する場合に限られるものではなく、検証辞書マスタの検証条件設定マスタ（図３参照）に基づいて、一連のデータを構成する各明細データ（例えば、「受注」や「出荷」など業務処理に関する各明細データ）の内容について整合性を検証するようにしてもよい。仮に、読み込んだ明細データの中に勘定科目が「旅費」である明細データがある場合には金額をチェックして、例えば、１０万円以上であれば整合性に問題があるデータとして、確定業務明細データＤＢにチェック情報を書き込む。

［データ検証装置による処理（実施例１）］
続いて、図８および図９を用いて、実施例１に係るデータ検証装置による処理を説明する。図８は、実施例１に係る明細データの収集および正規化処理の流れを示すフローチャートである。図９は、実施例１に係る検証処理の流れを示すフローチャートである。

［明細データの収集および正規化処理（実施例１）］
まず、図８を用いて、実施例１に係る明細データの収集および正規化処理の流れを説明する。同図に示すように、データ収集処理部２５ａは、ＥＳＢ内を流れる明細データを収集するとともに、明細データから伝票番号を取得する（ステップＳ８０１）。

具体的には、データ収集処理部２５ａは、例えば、受注の業務処理に関する受注入力指示を管理者などから受け付けた販売システムにおいて、伝票番号を採番した明細データがデータベースに登録されると、ＥＳＢ内を流れる受注入力処理の明細データを収集するとともに、明細データから伝票番号を取得する。

また、データ収集処理部２５ａは、受注入力処理に続いて、受注入力処理の明細データと同一の伝票番号を指定した受注可決指示を管理者などから受け付けた販売システムにより受注可決処理が実行されると、ＥＳＢ内を流れる受注可決処理の明細データを収集するとともに、明細データから伝票番号を取得する。同様にして、受注処理の明細データと同一の伝票番号を指定した出荷指示処理や出荷可決指示処理の明細データをＥＳＢからそれぞれ収集するとともに、各明細データから伝票番号を取得する。

次に、データ正規化処理部２５ｂは、データ収集処理部２５ａにより収集された明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与して正規化してＤＢに登録する（ステップＳ８０２）。

具体的には、データ正規化処理部２５ｂは、明細データの業務処理名が「受注入力」である場合には、業務手続処理として業務手続記録明細データＤＢ２４ｃに登録すべきものであると判定し、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢ２４ｃに登録する。

また、データ正規化処理部２５ｂは、データ収集処理部２５ａにより、受注入力処理の明細データと同一の伝票番号が指定された受注可決処理の明細データがＥＳＢ内から収集されると、業務手続処理として業務手続記録明細データＤＢ２４ｃに登録すべきものであると判定し、伝票番号を紐付けキーとして付与して正規化した明細データを業務手続記録明細データＤＢ２４ｃに登録するとともに、「受注可決」により受注の業務処理が確定することから、受注可決処理にまで至る明細データを確定業務明細データＤＢ２４ｂにも登録すべきものと判定し、伝票番号を紐付けキーとして付与して正規化した明細データを確定業務明細データＤＢ２４ｂに登録する。

同様にして、データ正規化処理部２５ｂは、受注処理（受注入力処理および受注可決処理）の明細データと同一の伝票番号が指定された出荷処理（出荷指示実行処理および出荷可決実行処理）の各明細データがＥＳＢ内から収集されると、各明細データから伝票番号を取得するとともに、各明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与して正規化した明細データを確定業務明細データＤＢ２４ｂや業務手続記録明細データＤＢ２４ｃにそれぞれ登録する。

なお、上述したデータ収集処理部２５ａおよびデータ正規化処理部２５ｂによる処理は、データ検証装置２０の電源投入時において繰り返し実行される。

［検証処理（実施例１）］
続いて、図９を用いて、実施例１に係る検証処理の流れを説明する。同図に示すように、例えば、管理者などから検証処理の実行指示を受け付けると（ステップＳ９０１肯定）、データ検証処理部２５ｃは、確定業務明細データＤＢ２４ｂから紐付けキーによって紐付けられる一連のデータを読み込む（ステップＳ９０２）。

次に、データ検証処理部２５ｃは、検証辞書マスタの検証プロセス設定マスタ（図３参照）に基づいて、確定業務明細データＤＢ２４ｂから読み込んだ一連のデータを並び替える（ステップＳ９０３）。例えば、勘定科目「売上」として計上された「受注」の各明細データ、「出荷」の各明細データおよび「債権」の各明細データで構成される一連のデータについて検証する場合には、検証プロセス設定マスタのチェック項目「科目」の「売上」について設定された処理順（例えば、条件が「受注」である場合には処理順「１」、条件が「出荷」である場合には処理順「２」、条件が「債権」である場合には処理順「３」など）に応じて、読み込んだ一連のデータを「受注」、「出荷」、「債権」の順に並び替える。

一連のデータを並び替えた後、データ検証処理部２５ｃは、並び替えられた一連のデータの整合性に問題があるか否か検証する（ステップＳ９０４）。例えば、処理日時（例えば、伝票日付）を降順にそれぞれ比較して処理日時の新旧の矛盾（例えば、「債権」の処理日時が「出荷」の処理日時より新しい日付である場合には矛盾）や一連のデータからの業務処理の一部欠落（例えば、出荷の「業務処理」に関するデータの欠落）、各データ間のデータ要素の不一致（例えば、商品名や取引先の不一致）などを検証する（図４参照）。

検証した結果、一連のデータ間の整合性に問題がある場合には（ステップＳ９０４肯定）、データ検証処理部２５ｃは、整合性に問題のあるデータについて、確定業務明細データＤＢ２４ｂにチェック情報を書き込む。チェック情報の書き込み後、または、一連のデータ間の整合性に問題がない場合には（ステップＳ９０４否定）、読み込み可能な一連のデータがあるか否か確認する（ステップＳ９０６）。確認の結果、読み込み可能な一連のデータがある場合には（ステップＳ９０６肯定）、引き続き確定業務明細データＤＢ２４ｂから読み込み可能な一連のデータを読み出して、上記で説明したのと同様に一連のデータの整合性に問題があるか否か検証する（ステップＳ９０４）。

一方、確認の結果、読み込み可能な一連のデータがない場合には（ステップＳ９０６否定）、確定業務明細データＤＢ２４ｂからチェック情報が書き込まれた明細データを読み込んで、例えば、図７に例示するように、伝票日時である処理日時、具体的なチェック内容および伝票番号からなる検証結果を出力する（ステップＳ９０７）。

なお、データ検証処理部２５ｃは、複数の明細データ間の整合性を検証する場合に限られるものではなく、検証辞書マスタの検証条件設定マスタ（図３参照）に基づいて、一連のデータを構成する各明細データ（例えば、「受注」や「出荷」など業務処理に関する各明細データ）の内容について整合性を検証するようにしてもよい。仮に、読み込んだ明細データの中に勘定科目が「旅費」である明細データがある場合には金額をチェックして、例えば、１０万円以上であれば整合性に問題があるデータとして、確定業務明細データＤＢにチェック情報を書き込む。

［実施例１による効果］
上述してきたように、実施例１によれば、業務処理単位（例えば、受注や出荷など）ごとにデータを収集し、前段の業務処理を引き継いだ後段の業務処理に係るデータが収集された場合に、前段の業務処理に係るデータと後段の業務処理に係るデータとを一連のデータ（例えば、受注データ、出荷データおよび売上データからなる一連のデータ）として紐付けるための紐付け情報（例えば、紐付けキーやリンクキーなどの情報）を付与して正規化して、紐付け情報とともに業務処理に係るデータをそれぞれ記憶しておき、記憶された複数のデータの中から紐付け情報により紐付けられる一連のデータを読み出し、一連のデータ間の整合性を所定の検証条件に基づいて検証して検証結果を出力する、すなわち、一連のデータを紐付けるための情報に基づいて、業務処理が引き継がれる一連のデータを記憶されたデータの中から抜き出すとともに、業務処理順序および業務処理内容からなる所定の検証条件（例えば、受注、出荷、売上の順にデータが計上されているか否かなどの条件）に基づいて、一連のデータの整合性を検証するので、従来人手で行われていた企業内の取引等に関わるデータの検証を簡易に行うことができ、また、複数のデータ間の整合性について検証することが可能である。

また、実施例１によれば、一連のデータ間の整合性のみならず、一連のデータを構成する各データの具体的な内容についても検証することが可能である。

また、上記の実施例１において、確定業務明細データＤＢ２４ｂに記憶されている複数のデータに、隠蔽性、不特定性およびリスクの程度（例えば、リスクについて「低」、「中」、「高」といった程度を示す情報）を示す情報を合わせて記憶するようにしてもよい。そこで、以下の実施例２では、実施例２に係るデータ検証装置の構成および処理を説明した後、実施例２による効果を説明する。

［データ検証装置の構成（実施例２）］
まず、実施例２に係るデータ検証装置の構成を説明する。実施例２に係るデータ検証装置は、実施例１に係るデータ検証装置と基本的には同様の構成（処理機能）を有するが、以下に説明する点が異なる。

すなわち、検証辞書マスタ２４ａは、検証条件設定マスタおよび検証プロセス設定マスタだけでなく、図１０に例示するように、検証項目設定マスタを備える。この検証項目設定マスタは、検証処理の条件項目（例えば、「勘定科目」や「取引先」など）、およびデータを絞り込むためのキー値（例えば、キー値１「旅費」やキー値２「預金」）に対応付けて、隠蔽性、不特定性およびリスクの程度を示す情報を設定するための情報（例えば、勘定科目の旅費である場合には、隠蔽性を「高」、不特定性を「高」、リスクを「低」に設定するための情報）を記憶して構成され、ユーザにより適宜設定可能である。

また、検証項目設定マスタの適用場面について具体的に説明すると、データ検証処理部２５ｃは、例えば、管理者などから検証処理の実行指示を受け付けて、まず、確定業務明細データＤＢ２４ｂから紐付けキーによって紐付けられる一連のデータを読み込む。そして、図１１に例示するように、読み込んだ一連のデータを検証項目設定マスタにそれぞれ照らし合わせて、隠蔽性、不特定性およびリスクの程度を示す情報を設定する（例えば、勘定科目の旅費である場合には、隠蔽性を「高」、不特定性を「高」、リスクを「低」に設定する）。

そして、上記の実施例１で説明したように、検証辞書マスタの検証プロセス設定マスタ（図３参照）に基づいて、確定業務明細データＤＢ２４ｂから読み込んだ一連のデータを並び替えた後、一連のデータ間の整合性等を検証する。具体的には、一連のデータ間の整合性に関する検証処理を終えると、データ検証処理部２５ｃは、例えば、一連のデータの中から隠蔽性が「高」に設定されている各明細データを抽出して、検証辞書マスタの検証条件設定マスタ（図３参照）に基づいて、各明細データ（例えば、「受注」や「出荷」など業務処理に関する各明細データ）の内容の整合性を検証する。例えば、一連のデータの中に隠蔽性が「高」に設定されている勘定科目が「旅費」の明細データを抽出して金額のチェックを行い、金額が１０万円以上であれば整合性に問題があるデータとして、確定業務明細データＤＢにチェック情報を書き込む。

［検証処理（実施例２）］
次に、図１２を用いて、実施例２に係る検証処理の流れを説明する。同図に示すステップＳ１２０１、ステップＳ１２０２、ステップＳ１２０４およびステップＳ１２０６〜ステップＳ１２０８までの処理は、図９を用いて上記の実施例１で説明したステップＳ９０１〜ステップＳ９０３およびステップＳ９０４〜ステップＳ９０７までの処理と同様であり、以下に説明するステップＳ１２０３およびステップＳ１２０５の処理が異なる。

すなわち、データ検証処理部２５ｃは、上記の実施例１で説明したのと同様に、例えば、管理者などから検証処理の実行指示を受け付けて、確定業務明細データＤＢ２４ｂから紐付けキーによって紐付けられる一連のデータを読み込むと（ステップＳ１２０２）、図１１に例示するように、読み込んだ一連のデータを検証項目設定マスタにそれぞれ照らし合わせて、隠蔽性、不特定性およびリスクの程度を示す情報を設定する（例えば、勘定科目の旅費である場合には、隠蔽性を「高」、不特定性を「高」、リスクを「低」に設定する）（ステップ１２０３）。

そして、上記の実施例１で説明したように、検証辞書マスタの検証プロセス設定マスタ（図３参照）に基づいて、確定業務明細データＤＢ２４ｂから読み込んだ一連のデータを並び替えた後、一連のデータ間の整合性等を検証する（ステップＳ１２０５）。具体的には、一連のデータ間の整合性に関する検証処理を終えると、データ検証処理部２５ｃは、例えば、一連のデータの中から隠蔽性が「高」に設定されている各明細データを抽出して、検証辞書マスタの検証条件設定マスタ（図３参照）に基づいて、各明細データ（例えば、「受注」や「出荷」など業務処理に関する各明細データ）の内容の整合性を検証する。例えば、一連のデータの中に隠蔽性が「高」に設定されている勘定科目が「旅費」の明細データを抽出して金額のチェックを行い、金額が１０万円以上であれば整合性に問題があるデータとして、確定業務明細データＤＢにチェック情報を書き込む。

［実施例２による効果］
上述してきたように、実施例２によれば、検証処理の条件項目（例えば、「勘定科目」や「取引先」など）、およびデータを絞り込むためのキー値（例えば、キー値１「旅費」やキー値２「預金」）に対応付けて、隠蔽性、不特定性およびリスクの程度を示す情報を設定するための情報（例えば、勘定科目の旅費である場合には、隠蔽性を「高」、不特定性を「高」、リスクを「低」に設定するための情報）を記憶しておき、記憶された隠蔽性、不特定性およびリスクの程度を示す情報（例えば、リスクについて「低」、「中」、「高」といった程度を示す情報）に応じて、記憶されている複数のデータの中からデータを抽出するとともに、検証条件設定マスタに基づいて抽出されたデータの内容をそれぞれ検証するので、データの内容に問題がある蓋然性の高いデータについて効率的に検証を行うことが可能である。

また、上記の実施例において、各種業務における業務処理単位ごとに収集された複数のデータをそれぞれ正規化する際に、各業務処理単位に共通するデータ項目（例えば、取引日や取引先、出張先などの業務処理に関する項目）で統一した形式にそれぞれ変換するようにしてもよい。そこで、以下の実施例３では、実施例３に係るデータ検証装置の構成および処理を順に説明した後に、実施例３による効果を説明する。

［データ検証装置の構成（実施例３）］
まず、実施例３に係るデータ検証装置の構成を説明する。実施例３に係るデータ検証装置は、上記の実施例に係るデータ検証装置と基本的には同様の構成（処理機能）を有するが、以下に説明する点が異なる。

すなわち、データ正規化処理部２５ｂは、データ収集処理部２５ａにより収集された明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与するだけでなく、さらに、各業務処理単位に共通するデータ項目（例えば、取引日や取引先、出張先などの業務処理に関する項目）で統一した形式にフォーマットを変換する正規化を行ってからＤＢに登録する。

具体的には、図１３に例示するように、データ正規化処理部２５ｂは、内部的に備える正規化フォーマット定義に基づいて、明細データ中の「科目」の項目を先頭に配置して、次に、「受注日」や「出荷日」、「売上日」等の明細データが登録されている項目を「取引日」の項目に統一変換して配置し、続いて、「受注部門」や「払出部門」、「計上部門」等の明細データが登録されている項目を「部門」の項目に統一変換して配置した後に、「受注金額」や「売上金額」等の明細データが登録されている項目を「金額」の項目に統一変換して配置して、残りの明細データが登録されている項目を配置するように正規化する。そして、図１４に例示するように、登録先として判定された確定業務明細データＤＢ２４ｂに正規化された明細データを登録する。

そして、データ検証処理部２５ｃは、例えば、確定業務明細データＤＢ２４ｂに記憶されている複数の明細データの中から一定期間内（例えば、一ヶ月など明細データの検証を行う期間内）に記憶されている複数の明細データをフォーマット変換したデータ項目（例えば、取引日や取引先など）ごとに読み出し、読み出された複数の明細データに関する整合性を所定の検証条件（例えば、同一の取引先との取引件数を月ごとに集計した集計値と所定の基準時との比較）に基づいて検証する。検証の結果、整合性に問題がある場合（例えば、同一の取引先との取引件数が異常に多いなど基準値と比較して差異が大きい場合など）には、確定業務明細データＤＢ２４ｂにチェック情報を書き込む。

なお、データ正規化処理部２５ｂは、フォーマット変換時に、データ収集処理部２５ａにより収集された明細データに記載されている業務処理名に基づいて、確定業務明細データＤＢ２４ｂの「業務」の項目に業務処理名を自動的に登録するようにしてもよい。

［明細データの正規化処理（実施例３）］
次に、図１５を用いて、実施例３に係る明細データの正規化処理の流れを説明する。同図に示すステップＳ１５０１の処理は、図８を用いて上記の実施例１で説明したステップＳ８０１の処理と同様であり、以下に説明するステップＳ１５０２の処理が異なる。

すなわち、データ正規化処理部２５ｂは、データ収集処理部２５ａにより収集された明細データに記載されている業務処理名に基づいてデータの登録先を判定して、明細データから取得した伝票番号を紐付けキーとして付与するだけでなく、さらに、各業務処理単位に共通するデータ項目（例えば、取引日や取引先、出張先などの業務処理に関する項目）で統一した形式にフォーマットを変換する正規化を行ってからＤＢに登録する（ステップＳ１５０２）。

具体的には、図１３に例示するように、データ正規化処理部２５ｂは、内部的に備える正規化フォーマット定義に基づいて、明細データ中の「科目」の項目を先頭に配置して、次に、「受注日」や「出荷日」、「売上日」等の明細データが登録されている項目を「取引日」の項目に統一変換して配置し、続いて、「受注部門」や「払出部門」、「計上部門」等の明細データが登録されている項目を「部門」の項目に統一変換して配置した後に、「受注金額」や「売上金額」等の明細データが登録されている項目を「金額」の項目に統一変換して配置して、残りの明細データが登録されている項目を配置するように正規化する。そして、図１４に例示するように、登録先として判定された確定業務明細データＤＢ２４ｂに正規化された明細データを登録する。

［実施例３による効果］
上述してきたように、実施例３によれば、各種業務における業務処理単位ごとに収集された複数のデータをそれぞれ正規化する際に、各業務処理単位に共通するデータ項目（例えば、取引日や取引先、出張先などの業務処理に関する項目）で統一した形式にそれぞれ変換して、例えば、確定業務明細データＤＢ２４ｂに記憶されている複数の明細データの中から一定期間内（例えば、一ヶ月など明細データの検証を行う期間内）に記憶されている複数の明細データをフォーマット変換したデータ項目（例えば、取引日や取引先など）ごとに読み出し、読み出された複数の明細データに関する整合性を所定の検証条件（例えば、同一の取引先との取引件数を月ごとに集計した集計値と所定の基準時との比較）に基づいて検証するので、例えば、データ項目ごとに一定期間内に行われた業務処理に関わるデータを読み出して、複数のデータに関する整合性を効率的に検証することが可能である。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

（１）単一の業務処理に係るデータの検証
上記の実施例では、主に、複数の明細データ間の整合性について検証する場合を説明したが、本発明はこれに限定されるものではなく、後段の業務処理に引き継がれることのなく業務が完結する単一の業務処理に係る明細データについて、例えば、検証条件設定マスタ（図３参照）に基づいて検証するようにしてもよい。

このようなことから、一連のデータ間の整合性のみならず、単独で完結する業務処理に係る明細データ（例えば、旅費）の具体的な内容についても検証することが可能である。

（２）複数の明細データ間の検証が行われるデータのみを収集
また、上記の実施例において、データ収集処理部２５ａは、複数の明細データ間の検証が行われるデータのみを収集するようにしてもよい。このようなことから、仮に、明細データ間の検証に関係のない“画面起動”や“起票者”、“起票端末名”などからなる業務操作記録データを収集している場合に必要なデータの絞込みを行なう必要がなく、複数の明細データ間の検証を効率的に実行することが可能である。

（３）装置構成等
また、図５に示したデータ検証装置２０の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、データ検証装置２０の分散・統合の具体的形態は図示のものに限られず、データ収集処理部２５ａとデータ正規化処理部２５ｂとを統合し、あるいは、データ収集処理部２５ａおよびデータ正規化処理部２５ｂが実現する処理機能を他の装置に分散するなど、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、データ検証装置２０にて行なわれる各処理機能（データ収集処理機能、データ正規化処理機能およびデータ検証処理機能、図８、図９等参照）は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（４）データ検証プログラム
ところで、上記の実施例で説明したデータ検証装置に係る各種の処理（例えば、図８、図９、図１２および図１５参照）は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、図１６を用いて、上記の実施例で説明したデータ検証装置と同様の機能を有するデータ検証プログラムを実行するコンピュータの一例を説明する。図１６は、データ検証プログラムを実行するコンピュータを示す図である。

図１６に示すように、データ検証装置としてコンピュータ３０は、通信制御Ｉ／Ｆ部３１、入力部３２、出力部３３、ＨＤＤ３４、ＲＡＭ３５、ＲＯＭ３６およびＣＰＵ３７をバス４０で接続して構成される。なお、通信制御Ｉ／Ｆ部３１、入力部３２および出力部３３は、例えば、図５に示したデータ検証装置２０の通信制御Ｉ／Ｆ部２１、入力部２２および出力部２３にそれぞれ対応する。

そして、ＲＯＭ３６には、上記の実施例に示したデータ検証装置と同様の機能を発揮するデータ検証プログラム、つまり、図１６に示すように、データ収集処理プログラム３６ａ、データ正規化処理プログラム３６ｂおよびデータ検証処理プログラム３６ｃがあらかじめ記憶されている。なお、これらのプログラム３６ａ、３６ｂおよび３６ｃについては、例えば、図５に示したデータ検証装置２０の各構成要素と同様、適宜統合または分散してもよい。なお、ＲＯＭ３６は、不揮発性の「ＲＡＭ」でもよい。

そして、ＣＰＵ３７が、これらのプログラム３６ａ、３６ｂおよび３６ｃをＲＯＭ３６から読み出して実行することで、図１６に示すように、各プログラム３６ａ、３６ｂおよび３６ｃは、データ収集処理プロセス３７ａ、データ正規化処理プロセス３７ｂおよびデータ検証処理プロセス３７ｃとして機能するようになる。なお、各プロセス３７ａ、３７ｂおよび３７ｃは、例えば、図５に示したデータ検証装置２０のデータ収集処理部２５ａ、データ正規化処理部２５ｂおよびデータ検証処理部２５ｃにそれぞれ対応する。

また、ＨＤＤ３４には、図１６に示すように、検証辞書マスタテーブル３４ａ、確定業務明細データテーブル３４ｂおよび業務手続記録明細データテーブル３４ｃがそれぞれ設けられる。これらの検証辞書マスタテーブル３４ａ、確定業務明細データテーブル３４ｂおよび業務手続記録明細データテーブル３４ｃは、例えば、図５に示した検証辞書マスタ２４ａ、確定業務明細データＤＢ２４ｂおよび業務手続記録明細データＤＢ２４ｃにそれぞれ対応する。そして、ＣＰＵ３７は、検証辞書マスタテーブル３４ａ、確定業務明細データテーブル３４ｂおよび業務手続記録明細データテーブル３４ｃから、検証辞書マスタデータ３５ａ、確定業務明細データ３５ｂおよび業務手続記録明細データ３５ｃをそれぞれ読み出してＲＡＭ３５に格納し、ＲＡＭ３５に格納された検証辞書マスタデータ３５ａ、確定業務明細データ３５ｂおよび業務手続記録明細データ３５ｃに基づいて処理を実行する。

なお、上記した各プログラム３６ａ、３６ｂおよび３６ｃについては、必ずしも最初からＲＯＭ３６に記憶させておく必要はなく、例えば、コンピュータ３０に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータ３０の内外に備えられるＨＤＤなどの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ３０に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶させておき、コンピュータ３０がこれらから各プログラムを読み出して実行するようにしてもよい。

以上のように、本発明に係るデータ検証装置、データ検証方法およびデータ検証プログラムは、複数段の業務処理からなる業務サービスについて、各業務処理におけるデータ間の検証を行うに有用であり、特に、従来人手で行われていた企業内の取引等に関わるデータの検証を簡易に行うことができ、また、複数のデータ間の整合性について検証することに適する。

Claims (12)

1. 複数の業務処理システムを含む業務サービスシステムにより実行される一連の業務処理の整合性の検証を行う検証装置であって、
   前記一連の業務処理の検証を行う際に設定される設定項目ごとに、前記一連の業務処理の業務処理順序を記憶する記憶手段と、
   前記複数の業務処理システム間でやり取りされるデータが経由するＥＳＢ（Enterprise Service Bus）から、各前記業務処理システムにおける業務処理単位ごとに、前記一連の業務処理で一意となる紐付け情報を含む明細データを収集するデータ収集手段と、
   前記データ収集手段により収集された明細データに含まれる前記紐付け情報を取得し、前記紐付け情報と、前記明細データとを対応付けてデータベースに記憶させるデータ記憶手段と、
   前記データベースから、設定された前記設定項目に該当し、かつ、同一の前記紐付け情報に対応付けられる明細データを読み出して、当該読み出した明細データを前記記憶手段に記憶される前記設定項目ごとの前記一連の業務処理の業務処理順序に従って並べ替え、並び替えた明細データが含む日時情報の順序が前記業務処理順序と一致するか否かを検証するデータ検証手段と、
   前記データ検証手段による検証結果を出力する検証結果出力手段と、
   を備えたことを特徴とする検証装置。
2. さらに、
   前記記憶手段は、前記一連の業務処理の整合性の検証を行う際に設定される設定項目ごとに、各前記業務処理システムにより実行される前記一連の業務処理に含まれる各業務処理における業務処理内容とともに当該業務処理内容の妥当性の判定基準を含む検証条件を記憶し、
   前記データ検証手段は、前記記憶手段により記憶されている前記検証条件に基づいて、前記データ記憶手段により対応付けされて前記データベースに記憶された際に正規化フォーマット定義に従って統一フォーマットへ変換された前記紐付け情報および前記明細データを前記データベースから読み出し、当該読み出した、同一の前記紐付け情報に対応付けられる明細データが示す前記業務処理内容および当該業務処理内容の妥当性を前記設定項目ごとに検証する
   ことを特徴とする請求項１に記載の検証装置。
3. さらに、
   前記記憶手段は、前記設定項目ごとに、検証対象となる明細データを絞り込むための絞込み情報と、絞り込んだ明細データを個別に検証するための検証内容と、前記絞り込み情報および前記検証内容に対応付けられ、前記業務処理ごとに設定される、検証の必要性のレベルを示す尺度情報とを含む個別検証条件を記憶し、
   前記データ収集手段は、前記データベースに一定期間に記憶され、かつ、前記記憶手段に記憶される前記個別検証条件に該当する明細データを前記ＥＳＢから取得して前記データベースに記憶させ、
   前記データ検証手段は、前記データベースに前記一定期間に記憶され、かつ、前記記憶手段に記憶される前記個別検証条件に該当する、同一の前記紐付け情報に対応付けられる明細データのうちの単一の明細データを前記データベースから読み出し、当該読み出した単一の明細データを前記個別検証条件に基づいて検証する
   ことを特徴とする請求項２に記載の検証装置。
4. 前記尺度情報は、前記明細データが示す金額の妥当性を検証する必要性のレベルを含む
   ことを特徴とする請求項３に記載の検証装置。
5. 複数の業務処理システムを含む業務サービスシステムにより実行される一連の業務処理の整合性の検証を行う検証装置が実行する検証方法であって、
   前記一連の業務処理の検証を行う際に設定される設定項目ごとに、前記一連の業務処理の業務処理順序を記憶手段に記憶させ、
   前記複数の業務処理システム間でやり取りされるデータが経由するＥＳＢ（Enterprise Service Bus）から、各前記業務処理システムにおける業務処理単位ごとに、前記一連の業務処理で一意となる紐付け情報を含む明細データを収集し、
   収集された明細データに含まれる前記紐付け情報を取得し、前記紐付け情報と、前記明細データとを対応付けてデータベースに記憶させ、
   前記データベースから、設定された前記設定項目に該当し、かつ、同一の前記紐付け情報に対応付けられる明細データを読み出して、当該読み出した明細データを前記記憶手段に記憶される前記設定項目ごとの前記一連の業務処理の業務処理順序に従って並べ替え、並び替えた明細データが含む日時情報の順序が前記業務処理順序と一致するか否かを検証し、
   検証した結果を出力する、
   各処理を実行することを特徴とする検証方法。
6. さらに、
   前記記憶手段に、前記一連の業務処理の整合性の検証を行う際に設定される設定項目ごとに、各前記業務処理システムにより実行される前記一連の業務処理に含まれる各業務処理における業務処理内容とともに当該業務処理内容の妥当性の判定基準を含む検証条件を記憶させ、
   前記記憶手段により記憶されている前記検証条件に基づいて、前記データ記憶手段により対応付けされて前記データベースに記憶された際に正規化フォーマット定義に従って統一フォーマットへ変換された前記紐付け情報および前記明細データを前記データベースから読み出し、当該読み出した、同一の前記紐付け情報に対応付けられる明細データが示す前記業務処理内容および当該業務処理内容の妥当性を前記設定項目ごとに検証する
   各処理を実行することを特徴とする請求項５に記載の検証方法。
7. さらに、
   前記記憶手段に、前記設定項目ごとに、検証対象となる明細データを絞り込むための絞込み情報と、絞り込んだ明細データを個別に検証するための検証内容と、前記絞り込み情報および前記検証内容に対応付けられ、前記業務処理ごとに設定される、検証の必要性のレベルを示す尺度情報とを含む個別検証条件を記憶させ、
   前記データベースに一定期間に記憶され、かつ、前記記憶手段に記憶される前記個別検証条件に該当する明細データを前記ＥＳＢから取得して前記データベースに記憶させ、
   前記データベースに前記一定期間に記憶され、かつ、前記記憶手段に記憶される前記個別検証条件に該当する、同一の前記紐付け情報に対応付けられる明細データのうちの単一の明細データを前記データベースから読み出し、当該読み出した単一の明細データを前記個別検証条件に基づいて検証する
   各処理を実行することを特徴とする請求項６に記載の検証方法。
8. 前記尺度情報は、前記明細データが示す金額の妥当性を検証する必要性のレベルを含む
   ことを特徴とする請求項７に記載の検証方法。
9. 複数の業務処理システムを含む業務サービスシステムにより実行される一連の業務処理の整合性の検証を行う検証装置としてのコンピュータに実行させる検証プログラムであって、
   前記コンピュータに、
   前記一連の業務処理の検証を行う際に設定される設定項目ごとに、前記一連の業務処理の業務処理順序を記憶手段に記憶させ、
   前記複数の業務処理システム間でやり取りされるデータが経由するＥＳＢ（Enterprise Service Bus）から、各前記業務処理システムにおける業務処理単位ごとに、前記一連の業務処理で一意となる紐付け情報を含む明細データを収集し、
   収集された明細データに含まれる前記紐付け情報を取得し、前記紐付け情報と、前記明細データとを対応付けてデータベースに記憶させ、
   前記データベースから、設定された前記設定項目に該当し、かつ、同一の前記紐付け情報に対応付けられる明細データを読み出して、当該読み出した明細データを前記記憶手段に記憶される前記設定項目ごとの前記一連の業務処理の業務処理順序に従って並べ替え、並び替えた明細データが含む日時情報の順序が前記業務処理順序と一致するか否かを検証し、
   検証した結果を出力する、
   各処理を実行させることを特徴とする検証プログラム。
10. さらに、
    前記コンピュータに、
    前記記憶手段に、前記一連の業務処理の整合性の検証を行う際に設定される設定項目ごとに、各前記業務処理システムにより実行される前記一連の業務処理に含まれる各業務処理における業務処理内容とともに当該業務処理内容の妥当性の判定基準を含む検証条件を記憶させ、
    前記記憶手段により記憶されている前記検証条件に基づいて、前記データ記憶手段により対応付けされて前記データベースに記憶された際に正規化フォーマット定義に従って統一フォーマットへ変換された前記紐付け情報および前記明細データを前記データベースから読み出し、当該読み出した、同一の前記紐付け情報に対応付けられる明細データが示す前記業務処理内容および当該業務処理内容の妥当性を前記設定項目ごとに検証する
    各処理を実行させることを特徴とする請求項９に記載の検証プログラム。
11. さらに、
    前記コンピュータに、
    前記記憶手段に、前記設定項目ごとに、検証対象となる明細データを絞り込むための絞込み情報と、絞り込んだ明細データを個別に検証するための検証内容と、前記絞り込み情報および前記検証内容に対応付けられ、前記業務処理ごとに設定される、検証の必要性のレベルを示す尺度情報とを含む個別検証条件を記憶させ、
    前記データベースに一定期間に記憶され、かつ、前記記憶手段に記憶される前記個別検証条件に該当する明細データを前記ＥＳＢから取得して前記データベースに記憶させ、
    前記データベースに前記一定期間に記憶され、かつ、前記記憶手段に記憶される前記個別検証条件に該当する、同一の前記紐付け情報に対応付けられる明細データのうちの単一の明細データを前記データベースから読み出し、当該読み出した単一の明細データを前記個別検証条件に基づいて検証する
    各処理を実行させることを特徴とする請求項１０に記載の検証プログラム。
12. 前記尺度情報は、前記明細データが示す金額の妥当性を検証する必要性のレベルを含む
    ことを特徴とする請求項１１に記載の検証プログラム。

Images