(57)【要約】【課題】金融機関に顧客から送金依頼がある場合、現在の顧客内の作業状況から金融機関内の所定時刻以降の業務量を推定し、事前準備させることが可能な仕組みを提供する。【解決手段】金融機関のシステムにおいて、顧客が送金依頼情報を作成開始したことを検出し、当該送金依頼情報に対する必要な顧客内のワークフローの各段階のステータスを管理する。また、送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録し、送金依頼情報の受付状況と登録されたカットオフタイム情報とに基づいて、金融機関内の後続の処理のタスク量を予測する。また、タスク量を予測した際に、所定の条件が満たされた場合、後続の作業を行う人員配置の調整を含む事前準備を開始させる。【選択図】図２
2019049944.tif 000002
【特許請求の範囲】
【請求項１】
金融機関における将来日付の送金処理に要する作業負荷を予測する方法であって、
前記金融機関のコンピュータが、
顧客が前記金融機関に対する送金依頼情報を作成開始したことを検出するステップと、
前記送金依頼情報に対する顧客内のワークフローの各段階のステータスを管理するステップと、
送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録するステップと、
前記送金依頼情報の受付状況と前記登録されたカットオフタイム情報とに基づいて、前記ワークフローの各段階の処理のタスク量を予測するステップと、
を実行することを特徴とする方法。
【請求項２】
前記タスク量を予測するステップにおいて、所定の条件が満たされた場合、前記顧客内での送金依頼承認後の前記金融機関による後続作業を行う人員配置の調整を含む事前準備を開始させることを特徴とする請求項１に記載の方法。
【請求項３】
前記タスク量を予測するステップにおいて、所定期間における時間帯ごとの予測件数と必要な人員数を含んだタスク量予測テーブルを作成し、前記金融機関の端末に表示させることを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記カットオフタイム情報を登録するステップにおいて、一般顧客と優遇顧客を区別する顧客サービスレベルごとに、カットオフタイム、送金実行日であるバリューデートに間に合わせるために前記金融機関における処理期限を調整するバリューデートオフセット、前記金融機関が最善努力した場合のカットオフタイム及びバリューデートオフセットであるベストエフォートを登録可能とすることを特徴とする請求項１から３までのいずれか１項に記載の方法。
【請求項５】
前記カットオフタイム情報を登録するステップにおいて、前記金融機関の繁忙期を登録し、前記繁忙期におけるカットオフタイム、バリューデートオフセット、ベストエフォートを登録可能とすることを特徴とする請求項４に記載の方法。
【請求項６】
前記ワークフローにおける最終承認者の端末に承認依頼の画面を表示するタイミングを制御するステップを更に含むことを特徴とする請求項１から５までのいずれか１項に記載の方法。
【請求項７】
金融機関における将来日付の送金処理に要する作業負荷を予測する金融機関システムのサーバであって、
顧客が前記金融機関に対する送金依頼情報を作成開始したことを検出する送金依頼情報取得手段と、
前記送金依頼情報に対する顧客内のワークフローの各段階のステータスを管理するステータス管理手段と、
送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録するカットオフタイム登録手段と、
前記送金依頼情報の受付状況と前記登録されたカットオフタイム情報とに基づいて、前記ワークフローの各段階の処理のタスク量を予測するタスク量予測手段と、
を備えることを特徴とするサーバ。
【請求項８】
請求項１に記載の各ステップをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、金融機関における将来日付の送金処理に要する作業負荷を予測して事前準備をさせるための仕組みに関する。
【背景技術】
【０００２】
従来、業務の発生を予測し、業務を効率化したり、顧客サービスを向上させたりするためのシステムが知られている。
【０００３】
例えば、特許文献１には、来店予約情報に基づき、予約受付管理システム、データ管理システム、店舗システムを相互に連携させ、事前の情報解析、人員配置、関連情報の取得、などにより、顧客獲得のための営業活動や、円滑な顧客支援のための業務効率化システムが開示されている。
【０００４】
また、特許文献２には、金融機関の勘定系システムの振込実行部の処理能力を監視する振込キャパシティ管理部と、当日に実行されるべき振込予約件数を格納した振込予約データベースとを備え、振込手数料割引システムの余力算出部は、当日にこれから発生する即時振込件数を統計情報に基づいて予測し、振込予約件数と予測された即時振込件数の合計と、振込キャパシティ管理部から取得した振込実行部の処理能力とを比較して、処理能力の当日の余力を算出し、算出された当日の処理能力の余力が所定の閾値よりも大きいと判定した場合に、算出された余力の範囲で、振込手数料を割引いた振込を受け付ける振込手数料割引システムが開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−２０７０４８号公報
【特許文献２】特開２０１４−１７０３１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記のようなシステムは、人的処理が必要な業務において、後続の処理を予測し、事前準備をさせるようなものではなかった。特に、銀行などの金融機関においては、様々なデータの作成、データのチェック、承認というワークフローが常に膨大に発生している。例えば、顧客からの送金依頼などは、ある作業が始まったら後続作業が発生することが予測できるので、事前準備させることで、その後の処理を効率化したり、ピーク時の作業負荷を軽減させたりすることができる。
【０００７】
したがって、本発明では、上記のような課題に鑑み、金融機関に顧客から送金依頼がある場合、現在の顧客内の作業状況から金融機関内の所定時刻以降の業務量を推定し、事前準備させることが可能な仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明は、以下のような解決手段を提供する。
【０００９】
（１）金融機関における将来日付の送金処理に要する作業負荷を予測する方法であって、前記金融機関のコンピュータが、顧客が前記金融機関に対する送金依頼情報を作成開始したことを検出するステップと、前記送金依頼情報に対する顧客内のワークフローの各段階のステータスを管理するステップと、送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録するステップと、前記送金依頼情報の受付状況と前記登録されたカットオフタイム情報とに基づいて、前記ワークフローの各段階の処理のタスク量を予測するステップと、を実行することを特徴とする。
【００１０】
（２）上記（１）に記載の方法において、前記タスク量を予測するステップにおいて、所定の条件が満たされた場合、前記顧客内での送金依頼承認後の前記金融機関による後続作業を行う人員配置の調整を含む事前準備を開始させることを特徴とする。
【００１１】
（３）上記（１）又は（２）に記載の方法において、前記タスク量を予測するステップにおいて、所定期間における時間帯ごとの予測件数と必要な人員数を含んだタスク量予測テーブルを作成し、前記金融機関の端末に表示させることを特徴とする。
【００１２】
（４）上記（１）から（３）までのいずれか１つに記載の方法において、前記カットオフタイム情報を登録するステップにおいて、一般顧客と優遇顧客を区別する顧客サービスレベルごとに、カットオフタイム、送金実行日であるバリューデートに間に合わせるために前記金融機関における処理期限を調整するバリューデートオフセット、前記金融機関が最善努力した場合のカットオフタイム及びバリューデートオフセットであるベストエフォートを登録可能とすることを特徴とする。
【００１３】
（５）上記（４）に記載の方法において、前記カットオフタイム情報を登録するステップにおいて、前記金融機関の繁忙期を登録し、前記繁忙期におけるカットオフタイム、バリューデートオフセット、ベストエフォートを登録可能とすることを特徴とする。
【００１４】
（６）上記（１）から（５）までのいずれか１つに記載の方法において、前記ワークフローにおける最終承認者の端末に承認依頼の画面を表示するタイミングを制御するステップを更に含むことを特徴とする。
【００１５】
（７）金融機関における将来日付の送金処理に要する作業負荷を予測する金融機関システムのサーバであって、顧客が前記金融機関に対する送金依頼情報を作成開始したことを検出する送金依頼情報取得手段と、前記送金依頼情報に対する顧客内のワークフローの各段階のステータスを管理するステータス管理手段と、送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録するカットオフタイム登録手段と、前記送金依頼情報の受付状況と前記登録されたカットオフタイム情報とに基づいて、前記ワークフローの各段階の処理のタスク量を予測するタスク量予測手段と、を備えることを特徴とする。
【００１６】
（８）上記（１）の方法に記載の各ステップをコンピュータに実行させることを特徴とするプログラム。
【発明の効果】
【００１７】
本発明によれば、金融機関に顧客から送金依頼がある場合、現在の顧客内の作業状況から金融機関内の所定時刻以降の業務量を推定し、事前準備させることが可能な仕組みを提供することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態に係る金融機関システムの基本概念を示す図である。
【図２】本発明の一実施形態に係る送金受付サーバの機能構成を示す図である。
【図３】本発明の一実施形態に係る受付データベース（ＤＢ）に格納されるデータの一例を示す図である。
【図４】タスク量予測テーブルの一例を示す図である。
【図５】カットオフタイム登録画面の一例を示す図である。
【図６】タスク量予測の処理フローを示す図である。
【図７】タスク量予測グラフのイメージを示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号又は符号を付している。
【００２０】
（システム構成）
図１は、本発明の一実施形態に係る金融機関システム（以下本システム）のシステム構成の概念を示す図である。本システムは、金融機関における将来日付の送金処理に要する作業負荷を予測し、予測結果が所定の条件を満たせば、金融機関内で必要な処置の事前準備を行わせるものである。以降の実施形態では、金融機関の業務の一例として、銀行の海外送金（外国送金）業務を例にとって説明するが、海外送金業務だけに限定するものではない。
【００２１】
図１に示すように、金融機関システム１０は、顧客企業であるＡ社、Ｂ社、Ｃ社のシステム（Ａ社システム２１，Ｂ社システム２２，Ｃ社システム２３等）と、顧客−銀行間のネットワーク４０を介して接続される。このネットワーク４０は、インターネットのような公衆ネットワーク回線であってもよいが、セキュリティが担保されたものであるとする。
【００２２】
顧客企業は、ネットワーク４０を介して、送金依頼を銀行に送信する。ここで顧客は、金融機関側が提供するシステム上で送金依頼情報を作成することが可能である。金融機関システム１０は、送金受付サーバ１００が送金依頼情報を受信し、受付ＤＢ１０２に送金依頼情報を格納する。顧客は、承認前であれば送金依頼情報をいつでも修正することができる。顧客企業側では、企業内部処理のためのワークフローに従って、担当者による送金依頼情報の作成、チェック者によるチェック、承認者による承認が行われる。一方、金融機関側では、顧客が送金依頼を作成し始めたときから処理状況のステータスを管理し、顧客側での作成から承認フローを経た送金依頼を受け付けて、金融機関の送金システムへ連動させ、その後、送金システムのオペレータによる送金電文の作成、承認プロセスが行われる。
【００２３】
金融機関システム１０内の受付ＤＢ１０２に行内での処理状況が格納されるが、顧客からの送金依頼の案件ごとに、データの作成中、作成完了（チェック待ち）、チェック中（精査中）、チェック済（承認待ち）、承認済などのステータスが把握可能である。したがって、案件全体のステータスを監視することで、将来日付の送金処理の作業負荷（所定時間後のタスク量）を予測することができる。例えば、タスク量予測グラフ３０のグラフで示すように、将来の時間軸に沿って、作成済件数、チェック済件数、承認済件数などのタスク量を、金融機関内の過去の実績に基づいて統計的に予測し、金融機関内の端末に表示する。
【００２４】
（機能構成）
図２は、本発明の一実施形態に係る金融機関システムにおける送金受付サーバの機能構成を示す図である。図示するように、金融機関システム１０は、送金受付サーバ１００を備えており、送金受付サーバ１００（以下、単にサーバということがある）は、前述したように、顧客が送金依頼情報を作成開始したことを検出し、顧客内での承認プロセスが終わるまでの状態を取得して格納する受付ＤＢ１０２に接続される。受付ＤＢ１０２は、サーバの内部にあってもよいし、サーバの外部にあってもよい。なお、送金依頼は通常、顧客のシステムとサーバとの間で電子的に行われるが、金融機関の支店の窓口、ＦＡＸ、電子メールなどで受け付けることもある。いずれにしろ、受け付けた送金依頼は送金依頼情報として電子化され、受付ＤＢ１０２に格納され、その後のステータスが常に管理される。
【００２５】
送金受付サーバ１００は、顧客企業の入力者が送金依頼情報を作成開始した時点で、データ作成プロセス、データ作成完了後のチェックプロセス、及び承認のプロセスのステータスを監視する。そのため受付ＤＢ１０２には、案件ごとに識別ＩＤが割り当てられ、ステータスが逐次更新される。データを作成完了後でなく、作成を開始した時点で監視を始めるのは、より早く後続の処理量を予測するためである。
【００２６】
特に海外への送金（外国送金）は、国内送金に比べ、必要な情報や手続が多く複雑であるため、入力やチェックに時間がかかるので、送金通貨ごと、送金種別ごとに、送金実行日（決済日又は送金取組日ともいう）であるバリューデート（Value Date）、及びバリューデートに間に合うための金融機関内の送金の承認時限であるカットオフタイム（Cut Off Time）が厳格に定められている。そのため、ワークフローの状況をデータ作成開始時から監視することで、後続の業務のチェック者や承認者に事前準備（適切な人員配置の調整や作業時間の確保を含む）をさせることが重要である。ここでは、案件数やそのステータス（取消も含む）だけでなく、送金内容（通貨、送金種別等）も管理される。
【００２７】
なお、送金受付サーバ１００は、顧客側のワークフローの状況を監視／表示可能である。また、送金システム内では、金融機関内の承認状況も監視可能である（図示するように、送金システム側での承認ワークフローがあってもよい）。
【００２８】
以下、図２に加え、図３、図４、図５を使って、送金受付サーバ１００の機能について詳しく説明する。以下では、金融機関を単に銀行と呼ぶことがある。
【００２９】
図２に示すように、送金受付サーバ１００は、送金依頼情報取得手段１０１、受付ＤＢ１０２、カットオフタイム登録手段１０４、ステータス管理手段１０５、金融機関端末表示制御手段１０６Ａ、顧客端末表示手段１０６Ｂ、タスク量予測手段１０７を備えている。以下各機能について順に説明する。
【００３０】
送金依頼情報取得手段１０１は、顧客から送金依頼の情報を作成段階から受け付けて、案件の識別子であるＩＤを割り振って受付ＤＢ１０２に格納する。ここで、顧客の入力者が、銀行システム内の送金データ作成画面を開いてデータを作成開始した時点からＩＤが付与される。入力者が入力は何もせず送金データ作成画面を閉じた場合はＩＤがリセットされるが、送金データ作成画面から所定の項目、例えば、入力者の氏名又は識別子、通貨などの基本データを入力し保存すれば、データが完成していなくともそのＩＤは保持される。
【００３１】
受付ＤＢ１０２は、送金依頼情報のデータの作成開始日時、作成完了日時（チェック依頼日時）、顧客内でのチェック完了日時（承認依頼日時）、承認完了日時、ステータスなどの管理情報を付加し、格納するデータベースである。顧客内での承認完了後の送金依頼は、銀行システムに通知され、銀行内の送金システム側での承認確認後、送金システムにより送金処理が行われる。
【００３２】
図３は、受付ＤＢ１０２に格納される送金データの一例を表形式で示したものである。図示するように、受付ＤＢ１０２には、「ＩＤ」、「通貨」、「顧客サービスレベル」、「カットオフタイム」、「バリューデートオフセット」、「ベストエフォート」等のデータが設定される。ここで設定されたデータに、「入力開始時刻」、「入力完了率」、「完了予測時刻」、「完了時刻」、現在の「ステータス」などのワークフロー管理情報がシステムによって自動付加される。以下、各項目について簡単に説明する。
【００３３】
「ＩＤ」は、送金依頼案件を識別するための情報である。このＩＤごとに、顧客からの送金依頼情報と銀行側で作成された送金データとが紐付けされる。「通貨」は、送金する金額の通貨である。
【００３４】
「顧客サービスレベル」とは、一般顧客と優遇顧客を区別し、送金依頼を発した顧客に対するサービスレベルを区別するための情報であり、レベル１（優遇レベル）の顧客は、レベル２（通常レベル）の顧客より銀行側の承認までの時間的制約を緩和したサービスが提供される。すなわち、優遇顧客に対しては、バリューデート直前までのデータの修正が可能となる。
【００３５】
「カットオフタイム」とは、前述したように、バリューデート（送金実行日）において銀行内の最終承認が完了していなければならない時刻（承認時限）である。カットオフタイムは、通貨、国、送金種別にあらかじめ設定されている。
【００３６】
「バリューデートオフセット」とは、金融機関における処理期限を調整するものであり、金融機関（銀行）側からみて、バリューデートから何日前に承認が完了していなければならないかを示す値で（何日前の何時何分という形で設定可能）ある。バリューデートオフセットは、顧客ごと又は顧客サービスレベルごとに設定可能であるが、優遇サービス対象であるレベル１の顧客は、通常のレベル２の顧客よりバリューデートの期限に近い（余裕時間が長い）バリューデートオフセットが設定可能である。
【００３７】
「ベストエフォート」とは、銀行側の処理能力に余裕がある場合に参照されるものであり、万一、バリューデート及びバリューデートオフセットから計算される日時を経過した場合であっても、銀行が最善努力をすることによってバリューデートに間に合わせる可能性がある受け付けを許容する期限前の日時を示す値である。例えば、バリューデートが８月１５日でバリューデートオフセットが「２日（前）」であるとすると、カットオフタイムが適用される日は８月１３日となる。このときベストエフォートのバリューデートオフセットに「１日（前）」が設定されていた場合は、８月１４日までに受け付けが完了していれば、ベストエフォートの対象になるということである。ただし、ベストエフォートが設定されていても必ずしもバリューデートに間に合うことが保証されるものではない。
【００３８】
図２に戻り、カットオフタイム登録手段１０４は、例えば、前述したカットオフタイム情報を登録可能とするカットオフタイム登録画面で構成される。カットオフタイム登録画面については後述の図５で具体例を説明する。
【００３９】
ステータス管理手段１０５は、顧客側での送金依頼情報作成に対するワークフローの各段階のステータスを管理する。ステータスは具体的には、顧客側の入力者がデータを作成中であることを示す「作成中」、データを作成し終わったことを示す「作成完了」（チェック待ち）、チェック者がチェック中であることを示す「チェック中」、チェック者がチェックを完了したことを示す「チェック済」（承認待ち）、承認者の端末に承認依頼が表示されたことを示す「承認中」、及び承認が完了したことを示す「承認済」などがある。もちろん、チェック者が不備を発見し、作成者に差戻した場合、承認者が否認した場合なども、そのことを示すステータスが格納される。
【００４０】
金融機関端末表示制御手段１０６Ａは、ステータス管理手段１０５と連携し、後述のタスク量予測手段１０７の予測結果に基づいて、金融機関端末２００に表示する画面を制御する。例えば、金融機関端末２００には、顧客が作成中及び作成完了後の最新ステータスが表示される。さらに、顧客のワークフローにおけるチェック完了予測時間、承認完了予測時間などを表示するようにしてもよい。また、顧客が送金依頼情報を承認した後の金融機関内で後続処理においてワークフローがある場合、金融機関内のオペレータ端末２０１には、そのオペレータが処理中の一覧及び最新ステータスが表示され、チェック者端末２０２には、そのチェック者に依頼された案件の一覧及び最新ステータスが表示されるようにしてもよい。また、金融機関の承認者端末２０３には、承認者が承認を依頼された案件の一覧及び最新のステータスが表示されるようにしてもよい。また、顧客端末表示制御手段１０６Ｂは、顧客端末３００に対し、顧客内のワークフローの各ステータスを顧客端末３００に表示するようにしてもよい。
【００４１】
また、金融機関端末表示制御手段１０６Ａは、タスク量予測手段１０７の予測結果（送金依頼件数など）に基づいて、承認画面の表示回数やタイミングを制御するようにしてもよい。この機能を「ジャストイン承認」と呼ぶことにする。
【００４２】
さらに、承認者は一般的には管理職であり外出することが多いので、端末表示制御手段１０６は、承認者の外出予定に基づいて承認画面を表示するようにしてもよい。すなわち、承認者が外出前、外出中でも承認可能なタイミングで承認画面を表示するようにする。より具体的には、承認者の外出スケジュールの時間帯を取得し、外出前に着信済みの承認依頼について承認作業が完了可能なタイミングで、承認画面を表示する。この機能を「スケジュール連動承認」と呼ぶことにする。
【００４３】
また、承認者が外出中でも予定の空き時間に、承認者端末２０３、又は場合によっては外部からでもアクセス可能な装置に承認作業画面を表示させ、作業を促すようにしてもよい。ジャストイン承認やスケジュール連動機能を備えることで、ワークフローの承認待ちの渋滞を緩和し、結果として、より安定したサービスの提供が可能となる。
【００４４】
タスク量予測手段１０７は、送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録し、送金依頼情報の受付状況と登録されたカットオフタイム情報とに基づいて、ワークフローの各段階の処理のタスク量を予測する機能を果たす。また、このとき、前述したように、データを作成中の段階から、作成完了までの完了予測時間、後続処理であるチェック時間（精査時間）、承認時間等を、過去のデータから統計的に予測する。ここでは、図４で示すタスク量予測テーブル１０８を作成し、それぞれの処理時間、件数を銀行内の管理端末に表示させる。同時にオペレータ端末２０１などに表示させるようにしてもよい。
【００４５】
図４は、タスク量予測テーブル１０８の一例を示したものである。タスク量予測テーブル１０８は、所定期間における時間帯ごとの予測件数とその件数を処理するための必要な人員数を含んだテーブルである。図の例は、最も単純なものであり、所定期間（この例では７月１２日〜１４日）において、時間帯を午前と午後に分け、その時間帯ごとに発生する件数を、現在及び過去のデータから統計的に予測し、各処理に必要な人員数（オペレータ数、チェック者数、承認者数）を計算したものである。この予測にはＡＩ（人工知能）の技術を用いてもよい。タスク量予測テーブル１０８に示された人員数が現在の人員数では不足する場合は、人員配置の調整などの事前準備が必要である。
【００４６】
なお、タスク量予測テーブル１０８の別の例としては、件数だけでなく、各タスクの処理時間と増減率をベースにしたものが考えられる。また、図７で示すようなタスク量予測グラフを併用してもよい。
【００４７】
以上で本システムの機能構成の説明を終わるが、上記のサーバの機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ(Solid State Drive)、ハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。
【００４８】
（画面例）
図５は、カットオフタイム登録画面の一例を示す図である。この図の例ではシンガポール支店のカットオフタイムの設定例が示されている。図示するカットオフタイム登録画面５００の英語表記「Currency」，「Transfer Sub Type」，「Start Busy Day」は、それぞれ「通貨」，「送金種別」，「繁忙期開始日」であり、これらの項目を設定する送金項目設定欄５０１，５０２，５０３が設けられている。送金種別は、細かくは、Main TypeとSub Typeが存在する。また、繁忙期開始日とは、その支店において繁忙期がスタートする日である（図示は省略しているが繁忙期終了日も設定してもよい）。例えば、月末日、月初日、五十日などが設定される。なお、図示は省略しているが、繁忙期開始日は複数設定してもよい。
【００４９】
Cut Off Time(カットオフタイム)の設定欄は、符号５１０で示すCustomer Service Level(顧客サービスレベル)及びBest Effort(ベストエフォート)を設定する領域と、符号５２０で示すNormal(通常)時期におけるカットオフタイムとバリューデートオフセットを設定する領域と、符号５３０で示すBusy(繁忙)期におけるカットオフタイムとバリューデートオフセットを設定する領域とに分けられる。既に述べたようにレベル１の顧客のほうが通常の顧客よりもバリューデートオフセット及びベストエフォートを、通常期及び繁忙期とも、よりバリューデートに近い日に設定できる。
【００５０】
また、符号５４０で示すCut Off Time List(カットオフタイムリスト)は、案件ごとに、通貨、送金種別、顧客サービスレベル別のカットオフタイム、バリューデートオフセット及び繁忙期開始日をリスト表示したものである。符号５４１の行は、ＳＧＤ（シンガポールドル）のInternal（同一支店振替）で、当日１６時のカットオフタイム、符号５４２の行は、ＳＧＤのTele（電信送金）で、当日１５時のカットオフタイム、符号５４３の行は、ＵＳＤ（米ドル）のIssue（小切手発行）で、前日(LV1 Value,LV2 Value（バリューデートオフセット）が１）の１２時のカットオフタイムの例が示されている。また、それぞれCustomer Service Level1(LV1)の顧客の場合とCustomer Service Level2(LV2)の顧客の場合が示されている。特に、符号５４３の行は、Level1 Best Effort(LV1 Best)がLevel2 Best Effort (LV2 Best)よりも４時間遅い期限が設定されていることに注意されたい。なお、図では通常期(Normal)の数値が表示されているが、繁忙期(Busy)の数値は、符号５４４で示す「・・・」の列以降に表示されるが、ここでは図を見やすくするために省略している。
【００５１】
（処理フロー）
図６は、タスク量予測手段１０７が実行するタスク量予測処理の流れを示す。タスク処理量予測には様々な方法が考えられるが、ここでは一例を説明する。なお、この処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。
【００５２】
タスク量予測手段１０７は、まず、ステップＳ１０において、データ入力を開始した案件があるかをチェックし、入力開始案件があれば、ステップＳ１１で、その案件を監視対象として登録し、以後案件ごとにステータスを監視する。
【００５３】
次にステップＳ１２において、全案件の状態から、あらかじめ定められた「事前準備モード」を開始する条件が満たされたか否かを判断する。「事前準備モード」とは、未処理の案件と処理完了の案件との増減率（滞留案件率）から、銀行内での人員配置の割振りの見直しや承認画面の表示タイミングの制御など、事前準備が必要と判断された場合に発動されるモードである。事前準備モード開始条件は、いろいろな条件によって判断され得るが、最も単純には、入力開始件数が所定値よりも多いか少ないかで判断してもよい。なお、オペレータが必ずしも支店にいる必要はなく、本店又は統括拠点において、各支店を担当する人員を再配置してもよい。
【００５４】
事前準備が必要か否かを判断するとき、図７に示すような、ある時点での作成中件数から当日の発生案件数を予測し、その後処理するチェック件数、承認件数の推移予測をグラフ化し、管理者に判断させるようにしてもよい。図７の例では、作成済件数が減少に転じ、かつチェック済件数が生じた時点を判断基準時とし、その時点で、チェック済件数、承認済件数の推移を予測したものである。図のように、このままでは、当日のカットオフタイムまでに全ての案件の承認処理が完了しないと判断されるときは、人員配置の見直しなどの何らかの処置が必要となる。
【００５５】
ステップＳ１２で事前準備モード開始条件に合致したと判断された場合は、ステップＳ１３において、事前準備モードが開始される。具体的には、ステップＳ１４において、案件数、案件種別、バリューデート、バリューデートオフセット、カットオフタイムに基づいて、チェック処理、承認処理に必要な人員数を計算する。このとき、図７の示すようなグラフで人員数を変化させてシュミレーションする。
【００５６】
さらに、ステップＳ１５において、所定時間後に作成案件数に対するチェック済件数及び承認済件数の率が所定値以上に収まっているかをチェックし、所定値を下回っている場合は、ステップＳ１４に戻り、人員数を再計算する。所定値以上に収まっている場合はステップＳ１６で事前準備モードをいったん終了して、ステップＳ１０に戻る。
【００５７】
（実施形態の効果）
以上で実施形態の説明を終わるが、本システムによれば、金融機関に顧客から送金依頼があった場合、現在の顧客内での作業状況から所定時刻以降の業務量を推定し、事前準備させることが可能な仕組みを提供することができる。
【００５８】
また、一般顧客と優遇顧客を区別する顧客サービスレベルごとに、カットオフタイム、バリューデートオフセット、ベストエフォートを登録することができる。また、金融機関の繁忙期を登録し、繁忙期におけるカットオフタイム、バリューデートオフセット、ベストエフォートを登録することもできる。
【００５９】
さらに、承認者の端末に承認依頼を表示するタイミングを制御し、承認者が外出中でも承認可能とすることで承認待ちの渋滞を緩和することができる。
【００６０】
なお、上記の実施形態では、銀行における海外送金業務を例にして説明したが、多数の案件を処理するためのワークフローを有する他の業務（例えば、宅配運送業など）にも応用が可能である。
【００６１】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されないことは言うまでもない。上記実施形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。また、そのような変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【００６２】
なお、上記の実施形態では、銀行における海外送金について説明したが、本発明は方法の発明として捉えることができ、また、本発明を金融機関システムのサーバ又はサーバのプログラムの発明としても捉えることもできる。
【符号の説明】
【００６３】
１０  金融機関システム
２１，２２，２３  顧客システム
３０  タスク量予測グラフ
４０  ネットワーク
１００  送金受付サーバ
１０１  送金依頼情報取得手段
１０２  受付ＤＢ
１０３  カットオフタイムリスト
１０４  カットオフタイム登録手段
１０５  ステータス管理手段
１０６  端末表示制御手段
１０６Ａ  金融機関端末表示制御手段
１０６Ｂ  顧客端末表示制御手段
１０７  タスク量予測手段
１０８  タスク量予測テーブル
２００  金融機関端末
２０１  オペレータ端末
２０２  チェック者端末
２０３  承認者端末
３００  顧客端末
５００  カットオフタイム登録画面
５０１，５０２，５０３  送金項目設定欄
５１０，５２０，５３０  カットオフタイム設定欄
５４０  カットオフタイムリスト表示欄
【図１】
2019049944.tif 000003
【図２】
2019049944.tif 000004
【図３】
2019049944.tif 000005
【図４】
2019049944.tif 000006
【図５】
2019049944.tif 000007
【図６】
2019049944.tif 000008
【図７】
2019049944.tif 000009
【手続補正書】
【提出日】平成30年10月9日(2018.10.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
金融機関における将来日付の送金処理に要する作業負荷を予測する方法であって、
前記金融機関のコンピュータが、
顧客が前記金融機関に対する送金依頼情報を作成開始したことを検出するステップと、
前記送金依頼情報に対する顧客内のワークフローの各段階のステータスを管理するステップと、
送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録するステップと、
前記送金依頼情報の受付状況と前記登録されたカットオフタイム情報とに基づいて、前記ワークフローの各段階の処理のタスク量を予測するステップと、
を実行することを特徴とする方法。
【請求項２】
前記タスク量を予測するステップにおいて、所定の条件が満たされた場合、前記顧客内での送金依頼承認後の前記金融機関による後続作業を行う人員配置の調整を含む事前準備を開始させることを特徴とする請求項１に記載の方法。
【請求項３】
前記タスク量を予測するステップにおいて、所定期間における時間帯ごとの予測件数と必要な人員数を含んだタスク量予測テーブルを作成し、前記金融機関の端末に表示させることを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記カットオフタイム情報を登録するステップにおいて、一般顧客と優遇顧客を区別する顧客サービスレベルごとに、カットオフタイム、送金実行日であるバリューデートに間に合わせるために前記金融機関における処理期限を調整するバリューデートオフセット、前記金融機関が最善努力した場合のカットオフタイム及びバリューデートオフセットであるベストエフォートを登録可能とすることを特徴とする請求項１から３までのいずれか１項に記載の方法。
【請求項５】
前記カットオフタイム情報を登録するステップにおいて、前記金融機関の繁忙期を登録し、前記繁忙期におけるカットオフタイム、バリューデートオフセット、ベストエフォートを登録可能とすることを特徴とする請求項４に記載の方法。
【請求項６】
前記送金依頼情報に対する前記金融機関内のワークフローにおける最終承認者の端末に承認依頼の画面を表示するタイミングを制御するステップを更に含むことを特徴とする請求項１から５までのいずれか１項に記載の方法。
【請求項７】
金融機関における将来日付の送金処理に要する作業負荷を予測する金融機関システムのサーバであって、
顧客が前記金融機関に対する送金依頼情報を作成開始したことを検出する送金依頼情報取得手段と、
前記送金依頼情報に対する顧客内のワークフローの各段階のステータスを管理するステータス管理手段と、
送金の承認時限であるカットオフタイム情報を、送金通貨、送金種別ごとに登録するカットオフタイム登録手段と、
前記送金依頼情報の受付状況と前記登録されたカットオフタイム情報とに基づいて、前記ワークフローの各段階の処理のタスク量を予測するタスク量予測手段と、
を備えることを特徴とするサーバ。
【請求項８】
請求項１に記載の各ステップをコンピュータに実行させることを特徴とするプログラム。