JP4763016B2

JP4763016B2 - 業務プロセスの適否確認システム及びプログラム

Info

Publication number: JP4763016B2
Application number: JP2008089515A
Authority: JP
Inventors: 諭大島; 康弘矢野
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2008-03-31
Filing date: 2008-03-31
Publication date: 2011-08-31
Anticipated expiration: 2028-03-31
Also published as: JP2009245067A

Description

この発明は業務プロセスの適否確認システム及びプログラムに係り、特に、ネットワーク経由で送信された各種データに基づいて、必要データの欠落やデータ相互間の整合性を確認することにより、業務プロセスが適正に執行されてきたか否かを自動的に判定し、その結果をディスプレイに表示させる技術に関する。

商品やサービスの取引を通じて生じた各種データ間において、相互に値が一致しているか否かを判定し、その結果をディスプレイに表示させる技術がすでに幾つか提案されている。

例えば、特許文献１における「売掛金照合システム」の場合、販売者の売上データと購入者の検収データを、販売者側の照合システムによって自動照合し、照合結果を照合履歴情報としてデータベースに格納すると共に、ディスプレイに表示させる技術が開示されている。

この売掛金照合システムによれば、照合結果の表示に際し、画面の左側に売上データがリストアップされると同時に、画面の右側に対応の検収データがリストアップされるため、ユーザは相互間における数量や単価、金額の差違を一目で認識することが可能となる。
特開平７−１２９６８５

しかしながら、この従来の照合システムの場合、照合対象となるのは売上及び検収の２種類のデータ間に限定されているため、人間にとって照合結果の比較が容易となる利点は確かにあるが、業務プロセスの適否を確認するという目的を達成するためには不十分であった。以下、商品の売買取引に付随して発生する具体的データを例示しつつ、この問題点について説明する。

すなわち、図１５に示すように、商品購入者から商品の注文が販売者に入ると、これを受けた営業所のコンピュータ80に受注データが入力される。また、この受注データに基づいて配送指示データが生成され、配送センターのコンピュータ81に送信される。これを受けた配送センターのコンピュータ81は、出荷データを生成し、これに基づいて購入者に対する商品の配送が実施される。そして、購入者から検収完了の通知がなされると、本社経理部のコンピュータ82に検収データが入力される。本社経理部のコンピュータ82は、最初の受注データと今回の検収データとを照合し、両者が一致すれば納品完了とみなして請求書データを生成する。つぎに、この請求書データに基づいて出力された請求書が購入者に送付され、購入者の銀行口座から販売者の銀行口座に対する送金処理が実行される。販売者の銀行から入金通知が届くと、本社経理部のコンピュータ82に入金データが入力される。最後に、本社経理部のコンピュータ82は、請求書データと入金データとを照合し、両者が一致することを確認する。

このような取引形態において、購入者から数量100個の注文が販売者に発せられた後、数量を20個減らす修正依頼がなされた場合、図１６に示すように、営業所のコンピュータ80には、数量「100」個の第１の注文データ83と、同じ注文書Noを備えた数量「−20」個の第２の注文データ84が入力される。したがって、本来であれば「100−20＝80」個分の配送指示データ及び出荷データが生成されるべきであるが、修正のタイミングが遅れて100個の商品が販売者から購入者に納品されてしまったと仮定する。このような場合、購入者側の検収時に20個余計に納品されていることが検知されればよいが、少なくとも80個は納品されているため、「適正」として検収完了通知が発せられる可能性が高い。このため、本社経理部のコンピュータ82には、数量「80」個の検収データ85が入力されてしまい、上記の照合時には注文数量＝80、検収数量＝80で両者が一致する結果、80個分の請求書が発行されることとなる。要するに、20個分の過剰納品が上記の照合処理では検出されずに、闇に消えてしまう結果となる。

本来であれば、上記の注文データ83、84及び検収データ85の他に、途中で発生する配送指示データ86または出荷データ87の少なくとも一方との間で照合処理を実行すれば、相互間の不一致を正しく検出することができる筈であるが、従来の照合システムでは２種類のデータ間での照合のみを対象としているため、上記のように途中で発生するデータを含めた３種類以上のデータ間における不整合を見落としてしまう危険性があった。

もちろん、２種データ間の照合機能のみを備えた従来の照合システムであっても、複数回の照合処理を実行することにより、上記の問題を解決することは不可能ではない。すなわち、図１７に示すように、まず注文データと出荷データ（または配送指示データ）間で照合処理を実行し、中間的な数量確認データを生成した後、これと検収データとを突き合わせて照合が完了した案件について請求書データを生成するようにすれば、上記のような途中における数量の不一致を事前に検出し、請求書データが生成される前に是正措置を講じることが可能となる。しかしながら、このように２種データ間の照合を多段階に繰り返すやり方では、当然ながら照合の回数が増えることとなり、処理の複雑化を招くこととなる。また、各照合の都度、必要データが揃うのを待つ必要があるため、全体的な処理時間が長くなるという問題が生じる。さらに、照合処理のためだけに利用される中間データも生成されるため、その分、システムのリソースを浪費する結果となる。

コンピュータによる自動照合処理は、上記のような物品の取引のみならず、金融商品の取引においても重要である。図１８はその一例として、信託銀行のシステム90が、機関投資家及び証券会社間における株式売買取引の適否を確認し、その結果に基づいて、管理を委託されている機関投資家の元帳(この例では資金元帳並びに株式元帳)の更新を行う場合の処理及びデータの流れを示している。

まず、機関投資家から証券会社に対して株式の買い注文が発せられると、機関投資家のシステム24から信託銀行のシステム90に対して注文データ60が送信される。その後、証券会社のシステム26から取引所のシステム（図示省略）に注文データが送信され、売買が成立すると証券会社のシステム26から信託銀行のシステム90に約定連絡データ（速報）61が送信される。

これを受けた信託銀行のシステム90は、注文データ60と約定連絡データ（速報）61とを夜間のバッチ処理で照合し（注文確認処理91）、注文内容が一致した場合には中間的な注文確認データ92を生成する。つぎに、証券会社のシステム26から信託銀行のシステム90に対し、今回の取引に要した実費や手数料、税金等を付加した売買報告データ（確報）62が送信される。これを受けた信託銀行のシステム90は、先に生成しておいた注文確認データ92と売買報告データ（確報）62とを夜間のバッチ処理によって照合し（注文完了確認処理93）、注文が完了したことを確認する。ここで照合が完了した場合には、信託銀行のシステム90によって証券会社の銀行口座に対する振込指示データ68が生成され、銀行のシステム30に送信される。同時に信託銀行のシステム90は、株券の入庫指示データ69を生成し、証券保管振替機構（以下「保振」）のシステム32に送信する。

銀行のシステム30においては、証券会社の銀行口座に対する必要金額の振込処理が実行され、その結果である入出金完了報告データ65が信託銀行のシステム90に送信される。同様に、保振のシステム32においても、指定された株券の入庫処理が実行され、その結果である入出庫完了報告データ66が信託銀行のシステム90に送信される。

信託銀行のシステム90は、まず振込指示データ68と入出金完了報告データ65を照合する（振込確認処理94）。つぎに信託銀行のシステム90は、入庫指示データ69と入出庫完了報告データ66とを照合する（入出庫確認処理95）。そして、振込確認処理94及び入出庫確認処理95が完了した時点で、信託銀行のシステム90は今回の取引が無事に完了したものとみなし、機関投資家の元帳データベースを更新する（元帳更新処理96）。

以上のように、２種類のデータ間での照合処理を夜間バッチで何度も繰り返すという従来の方式の下では、株式の売買取引の決済を完了するまでに、約定日（Ｔ）以降に４日間を要していた（これをＴ＋４決済と称する）。これに対し、株式をはじめとした有価証券取引における金融機関等の倒産等による決済不能となるリスクを軽減するため、約定日の翌日に決済を完了すべきであるという考え方が提唱されているが（これをＴ＋１決済と称する）、２種類のデータ間のみにおける夜間のバッチ照合を前提とする限り、Ｔ＋１決済の実現は覚束ないのが現状である。

また、元帳更新処理96は顧客である機関投資家の利害に直結するため極めて慎重かつ厳格に執行されるべきであり、振込確認処理94や入出庫確認処理95の後、入出金完了報告データや入出庫完了報告データと再度注文データ60や売買報告データ62との間でデータの整合性をチェックすることが望ましいといえる。しかしながら、従来の照合システムの場合には上記の通り、２種類のデータ間のみにおける特定項目の値の一致／不一致を単純に判定するにとどまるため、業務プロセスの無謬性を確認するためにはさらに多くの照合ステップを設ける必要が生じ、非現実的であった。

この発明は、このような従来の照合システムが抱えていた問題を解決するために案出されたものであり、同一取引に起因する３種類以上のデータ間における整合性の確認をデータ到着の都度逐次実行することにより、その間の業務プロセスの適否をチェックでき、チェック結果も視認性良く表示可能な技術を提供することを目的としている。

上記の目的を達成するため、請求項１に記載した業務プロセスの適否確認システムは、業務プロセスの進展によって取引毎に発生する３種類以上のデータ間の適合性の確認及び確認結果の表示を可能とする業務プロセスの適否確認システムであって、確認対象となる種々の受信データを、少なくとも取引ID、受信日時及びデータ種別を備えた標準フォーマットに変換し、共通の確認対象データ記憶手段に確認対象データとして格納する手段と、上記確認対象データ記憶手段内に格納された各確認対象データの適否を確認する確認処理手段と、上記確認対象データ記憶手段内に格納された各確認対象データのリストを含むディスプレイ表示用の画面を生成する画面生成手段とを備え、上記の確認処理手段は、上記確認対象データ記憶手段に新規の確認対象データが格納される度に、各確認対象データの取引IDに基づいて、業務プロセスの適否の確認に必要な相互に関連性のある他の種類の確認対象データが上記確認対象データ記憶手段内に存在しているか否かを確認し、業務プロセスの適否の確認に必要な確認対象データが揃っている場合には、その中の所定種類のデータ相互間における所定データ項目間の値を比較してその適否を確認し、この適否の確認結果を各確認対象データに記録する処理を実行し、必要な確認対象データが揃っていない場合には上記の適否確認をしないことを特徴とし、上記の画面生成手段は、オペレータの操作する端末から表示リクエストが入力された際に、上記確認対象データ記憶手段から各確認対象データを抽出し、業務プロセスの適否の確認に必要な確認対象データが揃い、上記適否の確認結果が記録された各確認対象データについては、各確認対象データの取引ID、受信日時、データ種別及び確認結果を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、業務プロセスの適否の確認に必要な確認データが揃ってはいないが、その中の２以上の種類の確認対象データについて受信が完了している場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、業務プロセスの適否の確認に必要な全ての種類の確認データが揃っておらず、その中の１種類の確認対象データのみが受信済みとなっている場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを縦方向に並べたリストを生成することを特徴としている。

請求項２に記載した業務プロセスの適否確認プログラムは、業務プロセスの進展によって取引毎に発生する３種類以上のデータ間の適合性の確認及び確認結果の表示を可能とする業務プロセスの適否確認プログラムであって、コンピュータを、確認対象となる種々の受信データを、少なくとも取引ID、受信日時及びデータ種別を備えた標準フォーマットに変換し、共通の確認対象データ記憶手段に確認対象データとして格納する手段、上記確認対象データ記憶手段内に格納された各確認対象データの適否を確認する確認処理手段、上記確認対象データ記憶手段内に格納された各確認対象データのリストを含むディスプレイ表示用の画面を生成する画面生成手段として機能させ、上記の確認処理手段が、上記確認対象データ記憶手段に新規の確認対象データが格納される度に、各確認対象データの取引IDに基づいて、業務プロセスの適否の確認に必要な相互に関連性のある他の種類の確認対象データが上記確認対象データ記憶手段内に存在しているか否かを確認し、業務プロセスの適否の確認に必要な確認対象データが揃っている場合には、その中の所定種類のデータ相互間における所定データ項目間の値を比較してその適否を確認し、この適否の確認結果を各確認対象データに記録する処理を実行し、必要な確認対象データが揃っていない場合には上記の適否確認をしないことを特徴とし、上記の画面生成手段が、オペレータの操作する端末から表示リクエストが入力された際に、上記確認対象データ記憶手段から各確認対象データを抽出し、業務プロセスの適否の確認に必要な確認対象データが揃い、上記適否の確認結果が記録された各確認対象データについては、各確認対象データの取引ID、受信日時、データ種別及び確認結果を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、業務プロセスの適否の確認に必要な確認データが揃ってはいないが、その中の２以上の種類の確認対象データについて受信が完了している場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、業務プロセスの適否の確認に必要な全ての種類の確認データが揃っておらず、その中の１種類の確認対象データのみが受信済みとなっている場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを縦方向に並べたリストを生成することを特徴としている。

請求項１に記載した業務プロセスの適否確認システム及び請求項２に記載した業務プロセスの適否確認プログラムによれば、ある一つの取引が元となって進展する業務プロセスに応じて発生する３種類以上のデータ間において、必要なデータ項目の値の適合性判定が可能となり、より高い確度で業務プロセスの適否を確認可能となる。
しかも、ネットワーク等を通じて送信元から送られた新たな確認対象データが格納される度に、確認処理に必要なデータの揃い具合がチェックされ、データが揃ったグループから順に確認処理が実行されるため、夜間バッチを前提とした従来の照合システムに比べ、迅速な処理が可能となる。
さらに確認結果が、各確認対象データを横１行形式で縦方向に並べたリスト状に、しかも同一取引に起因する一連のデータをまとめたグループ単位で区分された状態でディスプレイに表示されるため、３種類以上のデータ間における照合結果を、効率的に確認可能となる。
また、必要な確認対象データが揃っていないデータについても、その種類及び受信日時がリスト形式で表示されるため、必要なデータの遅延トラブルに対して迅速な対応が可能となる。

この発明の優位性は、従来の照合システムにおける「人間が行っていた２種類のみのデータ比較を機械に置き換えただけ」という発想から脱却し、「人手では不可能な３種類以上データの一括照合を実現し、業務精度とレスポンスの両方を向上させた」という点にあるといえる。
従来の照合システムの場合、２種類のデータ間における照合処理が前提のため、業務プロセスの適否を確認するには、上記のように照合処理を多段階に繰り返す必要があり、その都度、照合処理に必要な種類のデータが揃うのを待つ必要があった。これに対し、この発明の場合には共通の確認対象データ記憶手段に業務プロセスの適否判定に必要な全種類のデータが蓄積され、各データの到着順序に縛られることなく、必要なデータが揃った時点で一括処理が可能となるため、全体の処理速度を向上させることができる。

図１は、信託銀行のシステム10を示しており、この信託銀行のシステム10は、業務プロセスの適否確認システム12と、元帳管理システム18と、PCよりなる操作端末20とを備えている。

業務プロセスの適否確認システム12−元帳管理システム18間及び操作端末20−業務プロセスの適否確認システム12間は、それぞれLAN等の通信ネットワークによって接続されている。操作端末20には、OS及びデータ表示プログラムが搭載されている。

業務プロセスの適否確認システム12には、通信ネットワーク22を介して機関投資家のシステム24及び証券会社のシステム26が接続されており、また通信ネットワーク28を介して銀行のシステム30及び保振のシステム32が接続されている。

図２は、業務プロセスの適否確認システム12の機能構成を示すブロック図であり、データ受信部40と、受信データ記憶部42と、データ整形部44と、確認対象データ記憶部46と、確認処理部50と、表示画面生成部52と、確認結果送信部54とを備えている。データ受信部40、データ整形部44、確認処理部50、表示画面生成部52及び確認結果送信部54は、業務プロセスの適否確認システム12を構成するコンピュータのCPU が、OS及び専用のアプリケーションプログラムに従って必要な処理を実行することによって実現される。また、受信データ記憶部42及び確認対象データ記憶部46は、同コンピュータのハードディスク内に設けられている。

業務プロセスの適否確認システム12は、図３に示すように、機関投資家のシステム24から送信された注文データ60、証券会社のシステム26から送信された約定連絡データ（速報）61及び売買報告データ（確報）62の、３種類のデータ相互間における対応データの有無及び特定データ項目の値の一致／不一致を判定する注文完了確認処理（第１の業務プロセス確認処理）と、図４に示すように、銀行のシステム30から送信された入出金完了報告データ65、保振のシステム32から送信された入出庫完了報告データ66、蓄積済の標準フォーマット化された注文データ60'、蓄積済の標準フォーマット化された売買報告データ62'の、４種類のデータ相互間における対応データの有無及び特定のデータ間における所定項目の値の一致／不一致や適否を判定する決済完了確認処理（第２の業務プロセス確認処理）の２つの確認処理を実行する（詳細は後述）。

つぎに、図５のフローチャートに従い、業務プロセスの適否確認システム12における注文完了確認処理の手順を説明する。まず、機関投資家のシステム24または証券会社のシステム26から送信された確認対象データを業務プロセスの適否確認システム12が受信すると（Ｓ10）、データ受信部40によって受信データ記憶部42に格納される（Ｓ11）。ここで送信される照合対象データの種類としては、以下の(1)〜(3)のものがある。データ受信部40は、これら３種類のデータに対して受信日時情報を付加した上で、受信順に受信データ記憶部42に格納する。
(1)機関投資家のシステム24から証券会社のシステム26に対して送信されたものと同じ内容の株式の注文データ60
(2)証券会社のシステム26から機関投資家のシステム24に対して送信されたものと同じ内容の約定連絡データ（速報）61
(3)証券会社のシステム26から機関投資家のシステム24に対して送信されたものと同じ内容の売買報告データ（確報）62

受信データ記憶部42に新規データが格納されると、データ整形部44が起動し、当該照合対象データを標準フォーマットに順次変換した後（Ｓ12）、確認対象データ記憶部46に格納する（Ｓ13）。すなわち、上記(1)〜(3)のデータはそれぞれ独自のデータ項目やデータ形式を備えているため、このままでは効率的な照合が困難となる。そこで、データ整形部44によって事前に共通的なフォーマットに変換される。一例として、以下の変換処理がデータ整形部44によって実行される。
(イ) 各照合対象データのデータ項目の順番を、標準データのデータ項目の順番に統一させる。
(ロ) 後続の照合処理や決済処理に必要なデータ項目を補充する。
(ハ) 他のデータベースから必要な値を補充する。例えば、ブローカ名のみが記載されているデータについては、ブローカコードＤＢを参照し、対応のブローカコードを補う。

図６は、確認対象データ記憶部46に格納された、標準フォーマットに変換済みの各種確認対象データ、すなわち注文データ60'、約定連絡データ61'、売買報告データ62'を例示するものであり、取引ID、グループID、受信日時、確認結果（第１／第２）、確認日時（第１／第２）、データ種別、ブローカコード、銘柄コード、約定日、取引種別、取引数量、約定単価、入出金、入出庫等のデータ項目を備えている。図示の通り、データの種類（データ種別）を問わず、各確認対象データが同一のデータ項目を備えている。図示は省略したが、各照合対象データは他にも、手数料、税金、振込先名称、振込先口座、振込額、振込日、入庫元証券会社名、入庫元証券会社コード、出庫先証券会社名、出庫先証券会社コード、入出庫日等、金融関連データの交換上必要と想定される多数のデータ項目を備えている。

「取引ID」のデータ項目には、３種類の確認対象データが元々具有していた取引IDがそのまま記述される。この取引ID自体は、機関投資家のシステム24から送信された注文データ60の識別コードを、そのまま約定連絡データ及び売買報告データが引き継いだものであり、この取引IDの同一性によって異なる種類のデータ同士が一連の取引に係る関連データであるものと認定される。

一方、確認対象データ記憶部46に新規データが格納されると確認処理部50が起動し、注文完了確認処理に必要なグループが揃ったか否かを確認する。具体的には、当該新規データの取引IDを参照し、同じ取引IDを備えたデータが確認対象データ記憶部46内に存在しているか否かを判定し（Ｓ14）、同じ取引IDを備えた先行データが存在する場合には、既存データのグループIDを新規データに対して付与する（Ｓ15）。

つぎに確認処理部50は、必要な種類のデータが揃ったか否かを判定する（Ｓ17）。すなわち、この場面（注文完了確認処理）では注文データ60'、約定連絡データ61'、売買報告データ62'の３種類が揃った時点で初めて適正な確認処理が可能となるように予め設定されているため、確認処理部50は同一のグループIDを備えた３種類の確認対象データが確認対象データ記憶部46に揃っているか否かを判定する。

そして、この判定結果がYESの場合、確認処理部50は同一取引IDに係る注文、約定連絡、売買報告の３種類の確認対象データについて、注文完了確認のために必要なデータ項目（例えば、ブローカコード、銘柄コード、約定日、取引種別、取引数量、約定単価）における値が適正か否かを確認し（Ｓ20）、適正な場合には各確認対象データの第１の確認結果のデータ項目に「OK」を記録する（Ｓ21）。この際、確認日時も第１の確認日時項目に記録される。

確認対象データ記憶部46のデータに対して「OK」の記録がなされると、確認結果送信部54が起動し、この確認結果＝OKの売買報告データ62'に基づいて株式購入代金の振込指示データ68が生成され、銀行のシステム30に送信される（Ｓ23）。この振込指示データ68には、少なくとも取引IDと、振込先名称（証券会社名）、振込先口座（証券会社の銀行口座）、振込金額（取引数量×約定単価＋手数料＋税金）のデータが含まれている。また確認結果送信部54は、確認対象データ記憶部46に格納された注文データ60'及び売買報告データ62'の入出金項目に対し、振込指示済みのデータを記録する（Ｓ24）。

同時に確認結果送信部54は、売買報告データ62'に基づいて購入株券の入庫指示データ69を生成し、保振のシステム32に送信する（Ｓ25）。この入庫指示データには、少なくとも取引IDと、入庫元証券会社名、入庫元証券会社コード、銘柄コード、入庫数量のデータが含まれている。また確認結果送信部54は、確認対象データ記憶部46に格納された注文データ60'及び売買報告データ62'の入出庫項目に対し、入庫指示済みのデータを記録する（Ｓ26）。

上記のＳ14において同一取引IDの先行データが存在していなかった場合、確認処理部50は新規登録データについてグループIDを付与することなく、同じ取引IDを備えた後続データが格納されるまで待機させる（Ｓ16）。これに対し、同じ取引IDのデータが１件だけ存在した場合、確認処理部50は、この既存データ及び新規登録データ双方に共通のグループIDを付与する（Ｓ15）と同時に、必要な３種類のデータが揃っていないため（Ｓ17/N）、それぞれの第１の確認結果項目には「NG」を記録する（Ｓ18）。この場合、足りないデータが登録された時点で特定データ項目間の値の適否が判定され、適正の場合にはそれぞれのデータの第１の確認結果項目に「OK」が記録される（Ｓ17、Ｓ20、Ｓ21）。また、今回の処理には無関係であるが、例えば誤った二重送信などの理由により同一レコードが複数件格納されているような場合も正常な状態ではないためNGと判定される。

この業務プロセスの適否確認システム12にあっては、確認対象データ記憶部46に新規データが登録される度に、必要な種類のデータが揃ったか否かが確認されると共に、必要な種類のデータが揃った時点で順次所定のデータ項目の値が一致するか否かが判定されるため、夜間バッチを前提とした従来の照合システムに比べ、迅速な処理が可能となる。この結果、約定日の中に注文完了確認処理を実行し、銀行のシステム30に振込指示データ68を送信すると共に、保振のシステム32に入庫指示データ69を送信することができ、銀行のシステム30及び保振のシステム32における夜間バッチを考慮しても、翌日決済を企図したＴ＋１決済を実現することが可能となる。

つぎに、図７〜図９のフローチャートに従い、確認処理の結果表示に係る処理手順を説明する。まず、操作端末20から確認結果表示のリクエストが送信されると、これを受けた表示画面生成部52は（図７のＳ30）、図１０に示す表示対象選択画面70を送信する（Ｓ31）。

この表示対象選択画面70において、オペレータが注文／約定連絡／売買報告フォルダ71に包含される確認済フォルダ72配下の結果：NGフォルダ73をクリックし、展開される日付別フォルダの中から任意の日付（例えば2007/07/12）のフォルダを選択すると、対応の受信日を備えた確認対象データに係る確認結果NGリスト画面のリクエストが、業務プロセスの適否確認システム12に送信される。

これを受けた業務プロセスの適否確認システム12の表示画面生成部52は（Ｓ32）、確認対象データ記憶部46から確認結果がNGのデータを抽出し（Ｓ33）、確認結果NGリスト画面を生成した後、操作端末20に送信する（Ｓ34）。

図１１は、操作端末20のディスプレイに表示された確認結果NGリスト画面74の一例を示すものであり、横１行形式の注文データ60'、約定連絡データ61'、売買報告データ62'が、確認グループ単位で区分され、それぞれを縦方向に並べたリスト状態で表示されている。

例えば、確認グループ「X02155」の場合、約定連絡データ61'及び売買報告データ62'が揃っているものの、対応の注文データ60'が存在しないため、確認結果の表示項目に「NG」の文字が表示されると共に、データ種別項目が反転表示されている。

これに対し、確認グループ「X02164」の場合、注文データ60'の取引数量が「300」となっているのに対し、約定連絡データ61'及び売買報告データ62'の取引数量が共に「200」となっており、値が一致していないため、取引数量項目が反転表示されると共に、確認結果の表示項目に「NG」の文字が表示されている。

また、確認グループ「X02188」の場合には、注文データ60'にのみ銘柄コードとして「3214」が表示され、約定連絡データ61'及び売買報告データ62'の何れも銘柄コードが空白となっており、やはり値が一致していないため、銘柄コード項目が反転表示されると共に、確認結果の表示項目に「NG」の文字が表示されている。

このように、横１行形式の確認対象データが、確認グループ毎に縦方向に並べられたリスト状態でディスプレイに表示されるため、確認対象データの種類が３以上あっても、オペレータは確認結果を容易に一覧でき、問題の所在を即座に把握可能となる。なおオペレータは、「NG」が表示されている確認グループについては個別に原因を究明し、データ送信元に確認要求や再送要求を行ったり、問題が解決した場合にはマニュアル操作によって確認対象データの修正等を行うこともできる。

オペレータは、「OK」の確認結果を閲覧することもできる。すなわち、図１０の表示対象選択画面70において、オペレータが確認済フォルダ72配下の結果：OKフォルダ75をクリックし、展開される日付別フォルダ（図示省略）の中から任意の日付のフォルダを選択すると、対応の受信日を備えた確認対象データに係る確認結果OKリスト画面のリクエストが、業務プロセスの適否確認システム12に送信される。

これを受けた表示画面生成部52は（図８のＳ35）、確認対象データ記憶部46から確認結果がOKのデータを抽出し（Ｓ36）、確認結果OKリスト画面を生成した後、操作端末20に送信する（Ｓ37）。この結果、図示は省略したが、操作端末20のディスプレイには、確認結果OKリスト画面が表示される。この画面においても、横１行形式の注文データ60'、約定連絡データ61'、売買報告データ62'が、グループ単位で区分され、それぞれを縦方向に並べたリスト状態で表示される。そして、各データの確認結果の項目には「OK」の文字が記載されている。

図１０の表示対象選択画面70において、オペレータが待機中フォルダ76をクリックし、展開される日付別フォルダ（図示省略）の中から任意の日付のフォルダを選択すると、対応の受信日を備えた確認対象データに係る待機データリスト画面のリクエストが、業務プロセスの適否確認システム12に送信される。

これを受けた表示画面生成部52は（図９のＳ38）、確認対象データ記憶部46からグループIDが付与されていないデータを抽出し（Ｓ39）、待機データリスト画面を生成した後、操作端末20に送信する（Ｓ40）。この結果、図示は省略したが、操作端末20のディスプレイには、待機データリスト画面が表示される。この画面においては、未だグループIDが付与されていない横１行形式の確認対象データが、受信日時の古い順に１件毎に表示されている。待機データの受信日時がまだ新しい場合には他の必要データの到着を待てば良いが、データの受信日時から所定の時間が経過している場合、オペレータは何らかのトラブルが発生したものと認識し、必要な対応をタイムリーに講じる。

つぎに、図１２のフローチャートに従い、業務プロセスの適否確認システム12における決済完了確認処理の手順を説明する。まず、銀行のシステム30または保振のシステム32から送信された確認対象データを業務プロセスの適否確認システム12が受信すると（Ｓ50）、データ受信部40によって受信データ記憶部42に格納される（Ｓ51）。ここで送信される照合対象データとしては、以下の(1)及び(2)がある。データ受信部40は、これら２種類のデータに対して受信日時情報を付加した上で、受信順に受信データ記憶部42に格納する。
(1)銀行のシステム30から送信された入出金完了報告データ65
(2)保振のシステム32から送信された入出庫完了報告データ66

受信データ記憶部42に新規データが格納されると、データ整形部44が起動し、当該照合対象データを上記と同様の要領で標準フォーマットの入出金完了報告データ65'または入出庫完了報告データ66'に順次変換した後（Ｓ52）、確認対象データ記憶部46に格納する（Ｓ53）。

一方、確認対象データ記憶部46に新規データが格納されると、確認処理部50が起動し、決済完了確認処理に必要なグループが揃ったか否かを確認する。すなわち、入出金完了報告データ65'及び入出庫完了報告データ66'は、注文データ60から継承した取引IDをそれぞれ含んでいる。そこで確認処理部50は、当該新規データの取引IDを参照し、同じ取引IDを備えた注文データ60'及び売買報告データ62'が確認対象データ記憶部46内に存在しているか否かを判定し（Ｓ54）、これらのデータが存在する場合には、既存データのグループIDを新規データに対して付与する（Ｓ55）。これに対し、同じ取引IDを備えた注文データ60'及び売買報告データ62'が存在しない場合、入出金または入出庫の前提となる業務プロセス自体が存在しないこととなるため、確認処理部50は当該データの第２の確認結果項目に対して直ちに「NG」を記録する（Ｓ56）。

つぎに確認処理部50は、必要な種類のデータが揃ったか否かを判定する（Ｓ57）。すなわち、この場面（決済完了確認処理）では注文データ60'、売買報告データ62'、入出金完了報告データ65'、入出庫完了報告データ66'の４種類が揃った時点で初めて適正な確認処理が可能となるように予め設定されているため、確認処理部50は同一のグループIDを備えた４種類の確認対象データが確認対象データ記憶部46に揃っているか否かを判定する。

そして、この判定結果がYESの場合、確認処理部50は同一グループIDに係る４種類の照合対象データの中の少なくとも一部間について、決済完了確認のために必要なデータ項目の値が一致するか否か、あるいは値が適正か否かを確認し（Ｓ59）、その結果（OK／NG）を各確認対象データの第２の確認結果項目に記録する（Ｓ60、Ｓ61）。この際、確認日時も第２の確認日時項目に記録される。なお、上記Ｓ57における判定結果がNOの場合、確認処理部50は確認対象データの第２の確認結果項目にNGを記録する（Ｓ58）。

図１３は、この決済完了確認処理における確認事項を説明するための図であり、注文データ60'、売買報告データ62'、入出金完了報告データ65'、入出庫完了報告データ66'のデータ項目の一部が記載されている。この場合において確認処理部50は、例えば以下の確認処理を実行する。

(1)入出金の確認処理
注文データ60'、売買報告データ62'の入出金項目に「指示済」が記録されており、入出金完了報告データ65'の入出金項目に「済」が記録されていること。
(2)入出庫の確認処理
注文データ60'、売買報告データ62'の入出庫項目に「指示済」が記録されており、入出庫完了報告データ66'の入出庫項目に「済」が記録されていること。
(3)振込額の確認処理
入出金完了報告データ65'の振込額「629675」と、売買報告データ62'の取引数量、約定単価、手数料、税金の各項目の値から算出される合計額とが一致していること。
(4)入出庫数量の確認処理
注文データ60'、売買報告データ62'、入出庫完了報告データ66'の取引数量が一致していること。
(5)取引種別の確認処理
注文データ60'、売買報告データ62'、入出金完了報告データ65'、入出庫完了報告データ66'の取引種別が矛盾していないこと。すなわち、注文データ60'及び売買報告データ62'が「購入」であれば、入出金完了報告データ65'が「出金」、入出庫完了報告データ66'が「入庫」となっており、注文データ60'及び売買報告データ62'が「売却」であれば、入出金完了報告データ65'が「入金」、入出庫完了報告データ66'が「出庫」となっていること。

以上より明らかなように、確認処理部50は、全確認対象データの特定項目間の値が一致しているか否かを単純に照合するにとどまらず、同一確認グループに属する一部のデータ間において、ある項目と他の項目との値が整合しているか否か（矛盾がないか）、あるデータの一定範囲の項目の値の計算値と、他のデータの特定項目の値が一致しているか否か等、異なった観点からの多面的な確認処理を一括的に実行することができる。以上の確認事項はあくまでも一例であり、オペレータは必要に応じて様々な確認パターン（確認ルール）を予め設定しておくことができる。上記の(1)〜(5)の全てについて確認できた時点で、確認処理部50は各データの第２の確認結果項目に「OK」を記録する。

確認対象データ記憶部46に格納されたデータの第２の確認結果項目に「OK」が記録されると、確認結果送信部54が起動し、元帳更新データを元帳管理システム18に送信する（Ｓ62）。これを受けた元帳管理システム18は、元帳データベースにおける当該機関投資家の資金額及び保有株式に対し、必要な更新処理を実行する。

オペレータは、図１０に示した表示対象選択画面70において、注文／売買報告／入出金完了報告／入出庫完了報告フォルダ77、確認済フォルダ78及び結果：NGフォルダ（図示省略）を次々とクリックし、展開される日付別フォルダの中から任意の日付のフォルダを選択することにより、対応の受信日を備えた確認対象データに係る確認結果NGリスト画面をリクエストすることができる。

これを受けた表示画面生成部52は、確認対象データ記憶部46から第２の確認結果項目に「NG」が記録されたデータを抽出し、これらをグループID単位及び受信日単位でまとめた確認結果NGリスト画面を生成した後、操作端末20に送信する。

この結果、図示は省略するが、操作端末20のディスプレイには、確認結果NGリスト画面が表示される。この画面には、横１行形式の注文データ60'、売買報告データ62'、入出金完了報告データ65'、入出庫完了報告データ66'が、確認グループ単位で区分され、縦方向にリスト状に並んだ状態で表示される。そして、照合結果の項目にはそれぞれ「NG」の文字が表示されると共に、その原因となった項目が反転表示されているため、オペレータは即座に問題箇所を認識すると同時に、必要な対応を執ることが可能となる。

またオペレータは、上記と同様の手順を踏襲することにより、確認結果OKリスト画面や待機データリスト画面を操作端末20上で確認することもできる。

上記においては、この業務プロセスの適否確認システム12を金融取引において発生する各種データ間の確認処理に用いた例を説明したが、物品の取引に付随して生じるデータ間の確認処理に応用することも当然に可能である。例えば、図１６において説明した第１の注文データ83、第２の注文データ84、検収データ85、配送指示データ86、出荷データ87を業務プロセスの適否確認システム12に適時送信すれば、データ受信部40によって各データは一旦受信データ記憶部42に格納された後、データ整形部44によって標準フォーマットに順次変換され、第１の注文データ83'、第２の注文データ84'、検収データ85'、配送指示データ86'、出荷データ87'として確認対象データ記憶部46に格納される。そして、各データに対して確認処理部50による業務プロセスの確認処理が実行され、その判定結果が各データの確認結果項目に記録される。

図１４は、表示画面生成部52によって生成されたこの場合の確認結果NGリスト画面79を示すものであり、各データの確認結果項目には「NG」の判定結果が表示されると共に、数量項目及び金額項目が反転表示される結果、オペレータは配送指示データ85'と出荷データ86'が不正であることに一目で気が付き、業務プロセスの不整合を見落としたまま請求書が発行されることを未然に防止可能となる。

また、この確認システム12は、３種類以上のデータ間における確認処理においてその本領を発揮するものであるが、２種類のデータ間における確認処理についても適用可能であることはいうまでもない。

さらに、確認処理部50は、上記のようにグループIDに基づいて各確認対象データをグルーピングする代わりに、各確認対象データに付与された取引IDに基づいてグルーピングすることもできる。また、各データ同士をグルーピングするための項目としては、取引IDのように単一のキー項目に限定されるものではなく、複数のデータ項目を組み合わせることによってグルーピングすべき複数種類のデータを認識するように構成してもよい。

この発明に係る業務プロセスの適否確認システムを含む信託銀行のシステムの全体構成図である。業務プロセスの適否確認システムの機能構成を示すブロック図である。業務プロセスの適否確認システムにおける注文完了確認処理を中心とした各種データの流れを示す図である。業務プロセスの適否確認システムにおける決済完了確認処理を中心とした各種データの流れを示す図である。注文完了確認処理の手順を示すフローチャートである。標準フォーマットに変換された確認対象データを示す図である。確認処理の結果表示に係る処理手順を示すフローチャートである。確認処理の結果表示に係る処理手順を示すフローチャートである。確認処理の結果表示に係る処理手順を示すフローチャートである。表示対象選択画面を示す図である。確認結果NGリスト画面の一例を示す図である。決済完了確認処理の手順を示すフローチャートである。決済完了確認処理における確認事項を説明するための図である。業務プロセスの適否確認システムを物品の取引に付随して生じるデータ間の確認処理に応用した場合の、確認結果NGリスト画面の一例を示す図である。物品の売買取引に付随して発生するデータの一例を示す模式図である。従来のデータ照合の問題点を説明する図である。従来のデータ照合を多段階に実行する例を示す概念図である。従来のデータ照合を金融商品の取引に適用した例を示す模式図である。

符号の説明

10 信託銀行のシステム
12 業務プロセスの適否確認システム
18 元帳管理システム
20 操作端末
22 通信ネットワーク
24 機関投資家のシステム
26 証券会社のシステム
28 通信ネットワーク
30 銀行のシステム
32 保振のシステム
40 データ受信部
42 受信データ記憶部
44 データ整形部
46 確認対象データ記憶部
50 確認処理部
52 表示画面生成部
54 確認結果送信部
60 注文データ
60' 標準フォーマット化された注文データ
61 約定連絡データ
61' 標準フォーマット化された約定連絡データ
62 売買報告データ
62' 標準フォーマット化された売買報告データ
65 入出金完了報告データ
65' 標準フォーマット化された入出金完了報告データ
66 入出庫完了報告データ
66' 標準フォーマット化された入出庫完了報告データ
70 表示対象選択画面
74 確認結果NGリスト画面
79 確認結果NGリスト画面
83' 標準フォーマット化された第１の注文データ
84' 標準フォーマット化された第２の注文データ
85' 標準フォーマット化された検収データ
86' 標準フォーマット化された配送指示データ
87' 標準フォーマット化された出荷データ

Claims

業務プロセスの進展によって取引毎に発生する３種類以上のデータ間の適合性の確認及び確認結果の表示を可能とする業務プロセスの適否確認システムであって、
確認対象となる種々の受信データを、少なくとも取引ID、受信日時及びデータ種別を備えた標準フォーマットに変換し、共通の確認対象データ記憶手段に確認対象データとして格納する手段と、
上記確認対象データ記憶手段内に格納された各確認対象データの適否を確認する確認処理手段と、
上記確認対象データ記憶手段内に格納された各確認対象データのリストを含むディスプレイ表示用の画面を生成する画面生成手段とを備え、
上記の確認処理手段は、上記確認対象データ記憶手段に新規の確認対象データが格納される度に、各確認対象データの取引IDに基づいて、業務プロセスの適否の確認に必要な相互に関連性のある他の種類の確認対象データが上記確認対象データ記憶手段内に存在しているか否かを確認し、
業務プロセスの適否の確認に必要な確認対象データが揃っている場合には、その中の所定種類のデータ相互間における所定データ項目間の値を比較してその適否を確認し、この適否の確認結果を各確認対象データに記録する処理を実行し、必要な確認対象データが揃っていない場合には上記の適否確認をしないことを特徴とし、
上記の画面生成手段は、オペレータの操作する端末から表示リクエストが入力された際に、上記確認対象データ記憶手段から各確認対象データを抽出し、業務プロセスの適否の確認に必要な確認対象データが揃い、上記適否の確認結果が記録された各確認対象データについては、各確認対象データの取引ID、受信日時、データ種別及び確認結果を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、
業務プロセスの適否の確認に必要な確認データが揃ってはいないが、その中の２以上の種類の確認対象データについて受信が完了している場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、
業務プロセスの適否の確認に必要な全ての種類の確認データが揃っておらず、その中の１種類の確認対象データのみが受信済みとなっている場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを縦方向に並べたリストを生成することを特徴とする業務プロセスの適否確認システム。
業務プロセスの進展によって取引毎に発生する３種類以上のデータ間の適合性の確認及び確認結果の表示を可能とする業務プロセスの適否確認プログラムであって、コンピュータを、
確認対象となる種々の受信データを、少なくとも取引ID、受信日時及びデータ種別を備えた標準フォーマットに変換し、共通の確認対象データ記憶手段に確認対象データとして格納する手段、
上記確認対象データ記憶手段内に格納された各確認対象データの適否を確認する確認処理手段、
上記確認対象データ記憶手段内に格納された各確認対象データのリストを含むディスプレイ表示用の画面を生成する画面生成手段として機能させ、
上記の確認処理手段が、上記確認対象データ記憶手段に新規の確認対象データが格納される度に、各確認対象データの取引IDに基づいて、業務プロセスの適否の確認に必要な相互に関連性のある他の種類の確認対象データが上記確認対象データ記憶手段内に存在しているか否かを確認し、
業務プロセスの適否の確認に必要な確認対象データが揃っている場合には、その中の所定種類のデータ相互間における所定データ項目間の値を比較してその適否を確認し、この適否の確認結果を各確認対象データに記録する処理を実行し、必要な確認対象データが揃っていない場合には上記の適否確認をしないことを特徴とし、
上記の画面生成手段が、オペレータの操作する端末から表示リクエストが入力された際に、上記確認対象データ記憶手段から各確認対象データを抽出し、業務プロセスの適否の確認に必要な確認対象データが揃い、上記適否の確認結果が記録された各確認対象データについては、各確認対象データの取引ID、受信日時、データ種別及び確認結果を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、
業務プロセスの適否の確認に必要な確認データが揃ってはいないが、その中の２以上の種類の確認対象データについて受信が完了している場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを、相互に関連性のある複数種類の確認対象データの集まりであるグループ単位で縦方向に並べたリストを生成し、
業務プロセスの適否の確認に必要な全ての種類の確認データが揃っておらず、その中の１種類の確認対象データのみが受信済みとなっている場合には、各確認対象データの取引ID、受信日時及びデータ種別を少なくとも含む横１行形式のデータを縦方向に並べたリストを生成することを特徴とする業務プロセスの適否確認プログラム。