JP2014235686A - サーバ、習熟度算出方法及びプログラム - Google Patents

Abstract

【課題】オペレータの習熟度をより正確に算出することが可能なサーバ、習熟度算出方法及びプログラムを提供する。
【解決手段】オペレータによる帳票のエントリ処理時間を取得する処理時間取得部と、帳票の未処理件数を取得する未処理件数取得部と、前記処理時間取得部により取得された前記エントリ処理時間、前記未処理件数取得部により取得された前記未処理件数、および前記オペレータの識別情報を対応付けて記憶する記憶部と、前記オペレータの習熟度を、前記識別情報と対応付けられて前記記憶部に記憶された前記エントリ処理時間および前記未処理件数に基づいて算出する算出部と、を備えるサーバ。
【選択図】図１

Description

本発明は、サーバ、習熟度算出方法及びプログラムに関する。

一般的に、企業や工場などの組織においては、多数の仕事が複数人で分担して行われている。このような仕事の一例として、銀行などの金融機関における、複数のオペレータによる帳票のエントリ処理業務が挙げられる。

オペレータには、見習いからベテランまで様々な習熟度（スキル）を有する者が存在するため、同じ仕事であっても、品質や処理時間はオペレータのスキルに応じて異なる。そこで、オペレータのスキルを算出するための技術や、各オペレータのスキルに応じて適切な業務量を振り分けるための技術が開発されている。

例えば、下記特許文献１では、為替処理システムにおいて、担当者にスキルを設定し、難易度の高い帳票はスキルの高い担当者、難易度の低い帳票はスキルの低い担当者に割当てる技術が開示されている。

下記特許文献２では、オペレータの業務スキルを処理時間等から自動的に算出・更新する技術が開示されている。

下記特許文献３では、金融端末の取引操作において、入力時間や入力間違いを調査し評価する技術が記載されている。

特開２００８−１５２４９３号公報 特開２００５−２５８５５１号公報 特開２００１−３３１６５５号公報

ここで、金融機関でのエントリ業務のように、時期や時間帯によって仕事量に大きな変動がある場合、オペレータは、繁忙時には一生懸命をエントリ処理するものの、閑散時はゆっくりエントリ処理する傾向にある。このため、同一のエントリを処理する場合であっても、繁忙時と閑散時とでは処理時間が異なる。しかしながら、上記特許文献１に開示された技術では、単に処理時間に応じてオペレータの習熟度を算出するため、繁閑格差の影響で正確な習熟度を算出することが困難であるという問題があった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、オペレータの習熟度をより正確に算出することが可能な、新規かつ改良されたサーバ、習熟度算出方法及びプログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、オペレータによる帳票のエントリ処理時間を取得する処理時間取得部と、帳票の未処理件数を取得する未処理件数取得部と、前記処理時間取得部により取得された前記エントリ処理時間、前記未処理件数取得部により取得された前記未処理件数、および前記オペレータの識別情報を対応付けて記憶する記憶部と、前記オペレータの習熟度を、前記識別情報と対応付けられて前記記憶部に記憶された前記エントリ処理時間および前記未処理件数に基づいて算出する算出部と、を備えるサーバが提供される。

前記算出部は、対応付けられた前記未処理件数が多いほど大きな重み付けを行って前記エントリ処理時間を加重平均した値に基づいて前記習熟度を算出してもよい。

前記算出部は、閾値を超えている前記未処理件数に対応付けられた前記エントリ処理時間に基づいて前記習熟度を算出してもよい。

前記記憶部は、前記帳票の取り扱い金額をさらに対応付けて記憶し、前記算出部は、対応付けられた前記取り扱い金額が高いほど大きな重み付けを行って前記エントリ処理時間を加重平均した値に基づいて前記習熟度を算出してもよい。

前記記憶部は、前記帳票の処理期限をさらに対応付けて記憶し、前記算出部は、対応付けられた前記処理期限が短いほど大きな重み付けを行って前記エントリ処理時間を加重平均した値に基づいて前記習熟度を算出してもよい。

前記未処理件数は、前記オペレータひとり当たりの件数であってもよい。

前記サーバは、前記算出部により算出された前記習熟度に基づいて、前記オペレータに新たな前記帳票のエントリ処理業務を振り分ける振分部をさらに備えてもよい。

前記振分部は、新たな前記帳票の取り扱い金額および処理期限にさらに基づいて、前記エントリ処理業務を振り分けてもよい。

前記処理時間取得部は、前記オペレータにより操作されるエントリ端末により計測された前記エントリ処理時間を取得してもよい。

前記未処理件数取得部は、前記オペレータが前記帳票をエントリ処理した際の前記未処理件数を取得してもよい。

また、上記課題を解決するために、本発明の別の観点によれば、オペレータによる帳票のエントリ処理時間を取得するステップと、帳票の未処理件数を取得するステップと、取得された前記エントリ処理時間、および前記未処理件数を、前記オペレータの識別情報に対応付けて記憶するステップと、前記オペレータの習熟度を、前記識別情報と対応付けられて記憶された前記エントリ処理時間および前記未処理件数に基づいて算出するステップと、を備える習熟度算出方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、コンピュータに、オペレータによる帳票のエントリ処理時間を取得するステップと、帳票の未処理件数を取得するステップと、取得された前記エントリ処理時間、および前記未処理件数を、前記オペレータの識別情報に対応付けて記憶するステップと、前記オペレータの習熟度を、前記識別情報と対応付けられて記憶された前記エントリ処理時間および前記未処理件数に基づいて算出するステップと、を実行させるためのプログラムが提供される。

以上説明したように本発明によれば、オペレータの習熟度をより正確に算出することが可能である。

本発明の一実施形態に係るイメージエントリシステムの概要を示す説明図である。 本発明の一実施形態に係るエントリ端末の構成を示すブロック図である。 本発明の一実施形態に係るサーバの構成を示すブロック図である。 本発明の一実施形態に係る帳票ＤＢが記憶する情報の一例を示す説明図である。 本発明の一実施形態に係るオペレータ統計ＤＢが記憶する情報の一例を示す説明図である。 本発明の一実施形態に係る格納処理を示すフローチャートである。 本発明の一実施形態に係る取得処理を示すフローチャートである。 本発明の一実施形態に係る統計処理を示すフローチャートである。 本発明の一実施形態に係る振分け処理を示すフローチャートである。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

＜１．本発明の一実施形態に係るイメージエントリシステムの概要＞
まず、図１を参照して、本発明の一実施形態に係るイメージエントリシステムの概要について説明する。

図１は、本発明の一実施形態に係るイメージエントリシステムの概要を示す説明図である。図１に示すように、本発明の一実施形態に係るイメージエントリシステムは、帳票読取端末３０、サーバ２０、および複数のエントリ端末１０を有し、それぞれネットワークにより接続されている。

（帳票読取端末３０）
帳票読取端末３０は、帳票をスキャナにより読み取って、帳票のイメージデータを生成する装置である。帳票読取端末３０は、読み取って生成した帳票イメージを示すデータ（以下、帳票イメージデータとも称する）を、サーバ２０に送信する。

（エントリ端末１０）
エントリ端末１０は、オペレータ操作によりエントリ処理業務を行う端末である。エントリ端末１０は、帳票イメージデータを表示すると共に、オペレータによるデータ入力（以下、エントリ処理とも称する）を受け付ける。エントリ端末１０は、処理対象である帳票イメージデータをサーバ２０から受信して、エントリ処理を終えたデータ（以下、エントリデータとも称する）をサーバ２０に返信する。

（サーバ２０）
サーバ２０は、エントリ処理対象の帳票イメージデータを、オペレータの習熟度に応じて振り分ける機能を有する。具体的には、サーバ２０は、格納処理、取得処理、統計処理、振分け処理を行う。格納処理とは、サーバ２０が、帳票読取端末３０により生成された帳票イメージデータを記憶する処理である。取得処理とは、サーバ２０が、エントリ端末１０を操作するオペレータがエントリ処理に要する時間（エントリ処理時間）を取得する処理である。統計処理とは、サーバ２０が、オペレータの習熟度を算出する処理である。振分け処理とは、サーバ２０が、習熟度に基づいてオペレータにエントリ処理対象の帳票イメージデータを振り分ける処理である。

ここで、上述したように、上記特許文献では、オペレータの習熟度を処理時間から自動的に算出する技術が開示されている。しかしながら、時期や時間帯によって仕事量に大きな変動がある場合、エントリ処理時間に繁閑格差があるため、単にエントリ処理時間に基づくだけでは、オペレータの習熟度を正確に算出することが困難であるという問題があった。

金融機関のエントリ業務においては、月末がピーク日であり、ピーク日には通常日の約３倍もの処理件数が発生する場合がある。また、ゴトウビと呼ばれる５の倍数の日にはピーク日の半分程度ではあるが、通常日よりも多い処理件数が発生する場合がある。また、正午過ぎの時間帯に集中的に処理件数が発生する傾向もある。このように、金融機関のエントリ業務においては、時期や時間帯によって仕事量に大きな変動があるため、単にエントリ処理時間に基づくだけでは、オペレータの習熟度を正確に算出することが困難である。

また、帳票には、当日に処理しなければならない緊急性を要するものや、数日間の内に処理すればよいもの、金額が大きく重要度が大きいものなど、多様な種類がある。緊急性や重要度などは、エントリ処理時間に影響を与え得る要因であるが、上記特許文献ではこのような要因については何ら考慮されていない。

そこで、上記事情を一着眼点にして本発明の一実施形態に係るイメージエントリシステムを創作するに至った。本発明の一実施形態に係るイメージエントリシステムは、エントリ処理時間に影響を与える要因を加味することで、オペレータの習熟度をより正確に算出することができる。

具体的には、本発明の一実施形態に係るサーバ２０は、繁忙期や閑散期などの時期的要因、および緊急度や重要度などの帳票の属性に基づく属性的要因に基づいて、エントリ処理時間を加重平均する。サーバ２０は、これらの要因に基づいた加重平均を行うことにより、例えば繁忙時には一生懸命をエントリ処理し、逆に閑散時にはゆっくりエントリ処理する傾向によって生じる繁閑格差を補正することができる。属性的要因についても同様である。

そして、サーバ２０は、加重平均したエントリ処理時間に基づいて、オペレータの習熟度を算出する。習熟度は、上述の通り時期的要因が属性的要因による格差が補正されたエントリ処理時間に基づいて算出されるため、オペレータの業務スキルをより正確に反映している。

さらに、サーバ２０は、このようにして算出した習熟度に基づいて、各オペレータに対して帳票イメージデータを振り分ける。

以上、本発明に一実施形態に係るイメージエントリシステムの概要について説明した。続いて、イメージエントリシステムの詳細な構成および動作処理について、図２〜図９を参照して説明する。

＜２．実施形態＞
まず、図２および図３を参照して、エントリ端末１０およびサーバ２０の内部構成について説明する。

［２−１．エントリ端末の構成］
図２は、本発明の一実施形態に係るエントリ端末１０の構成を示すブロック図である。図２に示すように、エントリ端末１０は、通信部１１、制御部１２、表示部１３、操作部１４、およびエントリ時間計測部１５を有する。

（通信部１１）
通信部１１は、有線／無線により外部の情報装置との間でデータの送受信を行うための通信モジュールである。例えば、通信部１１は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）や電話回線などに接続され、サーバ２０と通信する。

本実施形態では、通信部１１は、帳票イメージデータの振り分け要求をサーバ２０に送信して、サーバ２０から振り分けられた帳票イメージデータを受信する。通信部１１は、受信した帳票イメージデータを制御部１２に出力する。ここで、振り分け要求には、エントリ端末１０を操作するオペレータを識別するための識別情報が含まれている。また、通信部１１は、制御部１２から出力されたエントリデータ、およびエントリ時間計測部１５から出力されたエントリ処理時間をサーバ２０に返信する。

（制御部１２）
制御部１２は、演算処理装置および制御装置として機能し、各種プログラムに従ってエントリ端末１０内の動作全般を制御する。制御部１２は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、マイクロプロセッサによって実現される。なお、制御部１２は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、および適宜変化するパラメータ等を一時記憶するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含んでいてもよい。

本実施形態では、制御部１２は、通信部１１から出力された帳票イメージデータを表示するよう、表示部１３を制御する。また、制御部１２は、操作部１４により受け付けられたオペレータからの入力情報に基づいてエントリ処理を実行して、エントリデータを生成する。そして、制御部１２は、生成したエントリデータを通信部１１に出力する。また、制御部１２は、表示部１３が帳票イメージデータを表示したことを示す情報、およびその帳票イメージデータについてのエントリ処理が終了したことを示す情報を、エントリ時間計測部１５に出力する。

（表示部１３）
表示部１３は、制御部１２による制御に基づいて、画像データ（静止画像／動画像）の表示を行う。表示部１３は、例えばＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）またはＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ−Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）、などにより実現される。

本実施形態では、表示部１３は、サーバ２０により振り分けられた帳票イメージデータを表示する。より詳しくは、表示部１３は、通信部１１によりサーバ２０から受信された帳票イメージデータを、制御部１２による制御に基づき表示する。

（操作部１４）
操作部１４は、オペレータによる操作に基づいて入力情報を受け付ける機能を有する。例えば、操作部１４は、キーボード、マウス等により実現される。

本実施形態では、操作部１４は、オペレータによる帳票のエントリ処理を受け付ける。より具体的には、操作部１４は、表示部１３により表示された帳票イメージデータに応じた、オペレータによるデータ入力を受け付ける。操作部１４は、受け付けた入力情報を制御部１２に出力する。

（エントリ時間計測部１５）
エントリ時間計測部１５は、オペレータによる帳票のエントリ処理時間を計測する機能を有する。具体的には、エントリ時間計測部１５は、表示部１３に帳票イメージデータが表示されてから、制御部１２によるエントリ処理が終了するまで、即ちエントリデータが生成されるまでの時間を、エントリ処理時間として計測する。エントリ時間計測部１５は、計測したエントリ処理時間を通信部１１に出力する。

以上、エントリ端末１０の内部構成について説明した。

［２−２．サーバの構成］
図３は、本発明の一実施形態に係るサーバ２０の構成を示すブロック図である。図３に示すように、サーバ２０は、通信部２１、帳票ＤＢ２２、習熟度算出部２３、オペレータ統計ＤＢ２４、および振分制御部２５を有する。

（通信部２１）
通信部２１は、有線／無線により外部の情報装置との間でデータの送受信を行うための通信モジュールである。例えば、通信部２１は、ＬＡＮや電話回線などに接続され、エントリ端末１０および帳票読取端末３０と通信する。

本実施形態では、通信部２１は、エントリ端末１０から帳票イメージデータの振り分け要求を受信する。そして、振り分け要求を振分制御部２５に出力し、振分制御部２５により振り分けられた帳票イメージデータを、エントリ端末１０に返信する。また、通信部２１は、エントリ端末１０によりエントリ処理されたエントリデータおよびエントリ処理時間を受信して帳票ＤＢ２２に出力する。ここで、通信部２１を、エントリ端末１０により計測されたオペレータによる帳票のエントリ処理時間を取得する、処理時間取得部としての機能を有すると捉えることができる。

なお、通信部２１は、帳票イメージデータをエントリ端末１０に送信してから、エントリ端末１０によりエントリ処理されたエントリデータを受信するまでにかかる時間を計測して、エントリ処理時間としてもよい。この場合、エントリ端末１０がエントリ時間計測部１５を有していない場合であっても、通信部２１はエントリ処理時間を取得することができる。

また、通信部２１は、帳票読取端末３０から帳票イメージデータを受信して、帳票ＤＢ２２に出力する。

（帳票ＤＢ２２）
帳票ＤＢ２２は、帳票に関する情報を記憶する記憶部としての機能を有する。帳票ＤＢ２２は、通信部２１により受信された各種情報に基づいて、新たに帳票に関する情報を追加したり、情報を更新したりする。ここで、図４を参照して、帳票ＤＢ２２が記憶する情報について説明する。

図４は、本発明の一実施形態に係る帳票ＤＢ２２が記憶する情報の一例を示す説明図である。図４に示すように、帳票ＤＢ２２は、１件の帳票について、帳票ＩＤ、処理日、受付日、帳票種別、帳票イメージデータ、オペレータＩＤ、エントリ処理時間、未処理件数、およびエントリデータを対応付けて記憶する。

帳票ＩＤとは、帳票を識別するための識別情報である。処理日とは、帳票がエントリ処理された日付を示す情報である。受付日とは、金融機関が顧客から帳票を受け付けた日付を示す情報である。帳票種別とは、帳票の種別を示す情報であり、一件式や連記式などがある。オペレータＩＤとは、オペレータを識別するための識別情報であり、その帳票をエントリ処理したオペレータを示している。未処理件数とは、オペレータが帳票をエントリ処理した際に、帳票ＤＢ２２が記憶している帳票データのうち、エントリ処理がなされていない（未処理の）、エントリ処理待ちの帳票データの件数を示す情報である。

通信部２１により帳票読取端末３０から帳票イメージデータが受信された場合、帳票ＤＢ２２は、新しく帳票ＩＤを生成して、受付日、帳票種別、および帳票イメージデータを対応付けて記憶する。ここで、受付日、帳票種別、および帳票イメージデータのみが記憶されている帳票データは、未処理である。図４に示した例では、帳票ＩＤが１０２または１０３の帳票データは未処理である。

一方で、通信部２１によりエントリ端末１０からエントリデータおよびエントリ処理時間が受信された場合、帳票ＤＢ２２は、処理日、エントリ処理したオペレータのオペレータＩＤ、未処理件数、エントリ処理時間、およびエントリデータを追加記憶する。つまり、受付日、帳票種別、および帳票イメージデータに加えて、処理日、オペレータＩＤ、エントリ処理時間、未処理件数、およびエントリデータが記憶されている帳票データは、エントリ処理済みである。図４に示した例では、帳票ＩＤが１００または１０１の帳票データはエントリ処理済みである。

帳票ＤＢ２２は、帳票の未処理件数を取得する未処理件数取得部としての機能も有する。帳票ＤＢ２２は、エントリ端末１０においてオペレータがエントリ処理した際、例えばエントリ端末１０への帳票イメージデータの送信時、またはエントリデータおよびエントリ処理時間の受信時に、未処理の帳票の総件数を取得する。そして、帳票ＤＢ２２は、取得した総件数を未処理件数として記憶する。なお、帳票ＤＢ２２は、総件数をオペレータの人数で割った、オペレータひとり当たりの件数を未処理件数として記憶してもよい。

なお、図４に示したデータはあくまで一例であり、本実施形態はかかる例に限定されない。例えば、帳票ＤＢ２２は、帳票の取り扱い金額や処理期限をさらに対応付けて記憶してもよい。

（習熟度算出部２３）
習熟度算出部２３は、オペレータの習熟度を、オペレータＩＤと対応付けられて帳票ＤＢ２２に記憶された帳票データの、エントリ処理時間および未処理件数に基づいて算出する、算出部としての機能を有する。

一般的に、オペレータの習熟度が高いほどエントリ処理時間は短く、低いほど長いと考えられる。しかし、上述したように、エントリ処理時間には繁閑格差があるため、単にエントリ処理時間に基づくだけではオペレータの習熟度を正確に測ることは困難である。ここで、繁忙時であるか閑散時であるかは、エントリ処理すべき帳票の多寡に現れると考えられる。即ち、繁忙時にエントリ処理された帳票に対応付けられた未処理件数は多く、逆に閑散時にはエントリ処理された帳票に対応付けられた未処理件数は少ないと考えられる。そこで、習熟度算出部２３は、エントリ処理時間に加えて未処理件数にさらに基づいて習熟度を算出することで、オペレータの習熟度を正確に測ることができる。

具体的には、習熟度算出部２３は、対応付けられた未処理件数が多いほど大きな重み付けを行い、未処理件数が少ないほど小さな重み付けを行って、エントリ処理時間を加重平均した値に基づいて習熟度を算出する。ここで、繁忙時のエントリ処理時間は、オペレータが一生懸命であるためオペレータの習熟度が直接的に反映されやすいが、閑散時のエントリ処理時間は、習熟度が高いオペレータであってもゆっくり処理するため、習熟度が直接的に反映され辛い。つまり、未処理件数が多い時のエントリ処理時間はより確からしく、未処理件数が少ない時のエントリ処理時間はより確からしくない。このため、習熟度算出部２３は、閑散時と比較してより確からしい繁忙時のエントリ処理時間により多く基づいて加重平均を行う。

習熟度算出部２３は、例えば次式により習熟度を算出する。

なお、上記数式１におけるｎは、対象期間における対象オペレータがエントリ処理した帳票の件数を示し、Ｔ_ｉは、ｉ件目の帳票のエントリ処理時間を示し、Ｎ_ｉは、ｉ件目の帳票をエントリ処理した際の未処理件数を示す。また、Ａｖｇ（Ｎ）は、対象期間における単位時間当たりの未処理件数の平均を示す。数式１に示したように、習熟度は、エントリ処理時間Ｔ_ｉの逆数が大きいほど、即ちエントリ処理時間Ｔ_ｉが短いほど大きな値となる。また、数式１に示したように、習熟度は、未処理件数Ｎ_ｉが多いほど大きな重み付けを行って算出される。さらに、未処理件数Ｎ_ｉは平均の未処理件数Ａｖｇ（Ｎ）により除算されるため、習熟度は、通常と比較して繁忙時のエントリ処理時間Ｔ_ｉに大きな重み付けを行い、通常と比較して閑散時のエントリ処理時間Ｔ_ｉに小さな重み付けを行って算出される。以下に、習熟度算出部２３が習熟度を算出する具体例を説明する。

例えば、４月のある日のある数分間において、オペレータＡおよびＢが、それぞれ２件の帳票をエントリ処理したものとする。４月の単位時間あたりの平均の未処理件数Ａｖｇ（Ｎ）は１００件であるものとする。この場合、未処理件数Ｎ_ｉが例えば２００件であれば繁忙時であり、８０件であれば閑散時である。

このような状況において、オペレータＡが、１件を未処理件数Ｎ_ｉが２００件のときに４０秒（Ｔ_ｉ）でエントリ処理し、１件を未処理件数Ｎ_ｉが８０件のときに１００秒（Ｔ_ｉ）でエントリ処理したものとする。この場合、オペレータＡの習熟度は、上記数式１により、２．９×１０^−２となる。一方で、オペレータＢは、１件を未処理件数Ｎ_ｉが２００件のときに５０秒（Ｔ_ｉ）でエントリ処理し、１件を未処理件数Ｎ_ｉが８０件のときに８０秒（Ｔ_ｉ）でエントリ処理したものとする。この場合、オペレータＢの習熟度は、上記数式１により、２．５×１０^−２となる。

オペレータＡは２件を合計１４０秒で処理し、オペレータＢは２件を合計１３０秒で処理しており、一見オペレータＢの方が習熟度は高いとも思えるものの、算出される習熟度はオペレータＡの方が高い。これは、オペレータＡが、繁忙時においてはオペレータＢよりも短いエントリ処理時間でエントリ処理しているからである。

以上具体例において説明したように、習熟度算出部２３は、繁忙時におけるエントリ処理時間により多く基づいて習熟度を算出する。このため、習熟度算出部２３は、繁忙時か閑散時かという時期的要因による格差を補正した、より正確な習熟度を算出することができる。

また、習熟度算出部２３は、所定の閾値を超えている未処理件数に対応付けられたエントリ処理時間に基づいて前記習熟度を算出してもよい。習熟度算出部２３は、繁忙時を示す閾値を設定することで、オペレータの習熟度が直接的に反映される繁忙時のエントリ処理時間のみに基づいた、より正確な習熟度を算出することができる。

また、習熟度算出部２３は、帳票の取り扱い金額が高いほど大きな重み付けを行ってエントリ処理時間を加重平均した値に基づいて習熟度を算出してもよい。さらに、習熟度算出部２３は、帳票に設定された処理期限が短いほど大きな重み付けを行ってエントリ処理時間を加重平均した値に基づいて習熟度を算出してもよい。一般的に、取扱い金額が高いほど重要度が高く、当日処理など処理期限が短いほど緊急度が高い。そして、重要度が高いほど、緊急度が高いほどオペレータは一生懸命に処理するため、習熟度が直接的に反映されやすく、エントリ処理時間はより確からしい。習熟度算出部２３は、取扱い金額が高いほど、処理期限が短いほど大きな重み付けを行って加重平均することで、重要度および緊急度という属性的要因による格差を補正した、より正確な習熟度を算出することができる。

なお、上述したように、帳票ＤＢ２２は、未処理の帳票データの総件数をオペレータの人数で割った、オペレータひとり当たりの件数を、未処理件数として記憶し得る。この場合、習熟度算出部２３は、上記数式１にオペレータひとり当たりの件数を用いることで、オペレータの総人数に起因する繁閑格差を補正することができる。以下、オペレータの総人数に起因する繁閑格差について説明する。

例えば、オペレータ数が１０人である場合に、処理件数が５０００件程度に達する時期は繁忙期であるとする。しかし、オペレータ数が仮に１００人であれば、処理件数が５０００件であっても繁忙期とは言い難い。また、処理件数が５００件であっても、オペレータ数が１人であれば繁忙期といえる。習熟度算出部２３は、未処理件数の総数に代えてオペレータひとり当たりの未処理件数を用いることで、このようなオペレータの人数に起因する繁閑格差を補正することができる。

習熟度算出部２３は、算出した習熟度をオペレータ統計ＤＢ２４に出力する。

（オペレータ統計ＤＢ２４）
オペレータ統計ＤＢ２４は、オペレータの属性情報を記憶する機能を有する。具体的には、オペレータ統計ＤＢ２４は、属性情報のひとつとして、習熟度算出部２３により算出された習熟度を記憶する。ここで、図５を参照して、オペレータ統計ＤＢ２４が記憶する情報について説明する。

図５は、本発明の一実施形態に係るオペレータ統計ＤＢ２４が記憶する情報の一例を示す説明図である。図５に示すように、オペレータ統計ＤＢ２４は、各オペレータについて、オペレータＩＤ、習熟度、およびその他の属性情報を対応付けて記憶する。図５に示した例では、習熟度をアルファベットで表しており、Ａが最も高い習熟度を表しており、Ｂ、Ｃ、Ｄになるにつれて徐々に低い習熟度を表している。図５に示した例では、オペレータＩＤが００３のオペレータの習熟度はＡで最も高く、００２のオペレータの習熟度はＣ、００３のオペレータの習熟度はＤとなっている。習熟度は、アルファベットの他にも、数値やその他の記号で表されてもよい。

（振分制御部２５）
振分制御部２５は、習熟度算出部２３により算出された習熟度に基づいて、オペレータに新たな帳票のエントリ処理業務を振り分ける振分部としての機能を有する。より具体的には、まず、振分制御部２５は、通信部２１により帳票イメージデータの振り分け要求が受信された場合に、送信元のエントリ端末１０を操作するオペレータの習熟度をオペレータ統計ＤＢ２４から取得する。そして、振分制御部２５は、帳票ＤＢ２２に記憶された未処理の帳票の中から、取得した習熟度に応じてひとつの帳票を選択し、選択した帳票を示す帳票イメージデータを通信部２１に出力する。

このとき、振分制御部２５は、帳票の取り扱い金額および処理期限にさらに基づいて、エントリ処理業務を選択する。具体的には、振分制御部２５は、習熟度が低いオペレータに対しては、緊急度または重要度が高い帳票を避けて、即ち処理期限が長く取扱い金額が低い帳票の帳票イメージデータを、振り分けるエントリ処理業務として選択する。このようにして、振分制御部２５は、オペレータの習熟度に適する帳票を振り分けることができる。

上述したように、振分制御部２５が出力した帳票イメージデータは、通信部２１により振り分け要求の送信元であるエントリ端末１０に返信される。

以上、エントリ端末１０の内部構成について説明した。

［２−３．動作処理］
続いて、本実施形態に係るイメージエントリシステムの動作処理について説明する。上述したように、本実施形態に係るイメージエントリシステムの動作処理は、格納処理、取得処理、統計処理、振分け処理に分けられる。以下、図６〜図９を参照して、これらの動作処理について順に説明する。

（２−３−１．格納処理）
図６は、本発明の一実施形態に係る格納処理を示すフローチャートである。図６に示すように、まず、ステップＳ１０２で、帳票読取端末３０は、金融機関店舗で受け付けた帳票や、金融機関の事務センターに送られてきた帳票をスキャンして読み取る。

次いで、ステップＳ１０４で、帳票読取端末３０は、帳票を読み取って生成した帳票イメージデータを、サーバ２０に送信する。

そして、ステップＳ１０６で、サーバ２０の帳票ＤＢ２２は、通信部２１により帳票読取端末３０から受信された帳票イメージデータを記憶する。このとき、帳票ＤＢ２２は、図４に示したように、帳票ＩＤ、帳票イメージデータ、受付日および帳票種別を対応付けて記憶する。なお、帳票ＤＢ２２は、帳票の取り扱い金額や処理期限をさらに対応付けて記憶してもよい。

以上、本実施形態に係る格納処理について説明した。

（２−３−２．取得処理）
図７は、本発明の一実施形態に係る取得処理を示すフローチャートである。図７に示すように、まず、ステップＳ２０２で、サーバ２０の通信部２１は、帳票イメージデータをエントリ端末１０に送信する。

次いで、ステップＳ２０４で、エントリ端末１０の表示部１３は、通信部１１によりサーバ２０から受信された帳票イメージデータを表示する。次に、ステップＳ２０６で、エントリ時間計測部１５は、エントリ処理時間の計測を開始する。次いで、ステップＳ２０８で、操作部１４は、オペレータからのデータ入力を受け付け、制御部１２はオペレータからの入力情報に基づいてエントリ処理を実行して、エントリデータを生成する。そして、ステップＳ２１０で、エントリ時間計測部１５は、エントリ処理時間の計測を終了する。このようにして、エントリ時間計測部１５は、表示部１３に帳票イメージデータが表示されてから、制御部１２によるエントリ処理が終了するまで、即ちエントリデータが生成されるまでの時間を、エントリ処理時間として計測する。

次に、ステップＳ２１２で、エントリ端末１０の通信部１１は、制御部１２により生成されたエントリデータ、およびエントリ時間計測部１５により計測されたエントリ処理時間を、サーバ２０に送信する。

次いで、ステップＳ２１４で、帳票ＤＢ２２は、帳票データの未処理件数を取得する。

そして、ステップＳ２１６で、帳票ＤＢ２２は、通信部２１により受信されたエントリデータおよびエントリ処理時間、オペレータＩＤ、未処理件数、および処理日を、対応する帳票ＩＤを有する帳票データに追加記憶する。

以上、本実施形態に係る取得処理について説明した。

（２−３−３．統計処理）
図８は、本発明の一実施形態に係る統計処理を示すフローチャートである。ここでは、ひとりのオペレータの習熟度を算出する処理について説明する。図８に示すように、まず、ステップＳ３０２で、習熟度算出部２３は、帳票ＤＢ２２に格納されている、習熟度算出対象のオペレータを示すオペレータＩＤに対応付けられた情報を取得する。

そして、ステップＳ３０４で、習熟度算出部２３は、取得した情報に基づいて習熟度を算出する。より詳しくは、習熟度算出部２３は、上記数式１を用いて、対応付けられた未処理件数が多いほど大きな重み付けを行い、未処理件数が少ないほど小さな重み付けを行って、エントリ処理時間を加重平均した値に基づいて習熟度を算出する。このとき、習熟度算出部２３は、所定の閾値を超えている未処理件数に対応付けられたエントリ処理時間のみを用いてもよいし、取扱い金額が高いほど、処理期限が短いほど大きな重み付けを行って加重平均してもよい。

次いで、ステップＳ３０６で、オペレータ統計ＤＢ２４は、習熟度算出部２３により算出された習熟度を、オペレータＩＤに対応付けて記憶する。

次に、ステップＳ３０８で、習熟度算出部２３は、統計処理を終了するか否かを判定する。統計処理を終了しない場合（Ｓ３０８／ＮＯ）、ステップＳ３１０で、処理は所定期間経過するまで中断して、ステップＳ３０２に戻る。このようにして、習熟度算出部２３は、定期的／自動的に習熟度を算出および更新することができるため、人による管理負担が軽減される。一方で、統計処理を終了する場合（Ｓ３０８／ＹＥＳ）、処理は終了する。

以上、本実施形態に係る統計処理について説明した。

（２−３−４．振分け処理）
図９は、本発明の一実施形態に係る振分け処理を示すフローチャートである。図９に示すように、まず、ステップＳ４０２で、エントリ端末１０の通信部１１は、帳票イメージデータの振り分け要求をサーバ２０に送信する。

次いで、ステップＳ４０４で、サーバ２０の振分制御部２５は、振り分け要求の送信元のエントリ端末１０を操作しているオペレータのオペレータＩＤに対応付けられた習熟度を、オペレータ統計ＤＢ２４から取得する。

次に、ステップＳ４０６で、振分制御部２５は、取得した習熟度に応じた未処理の帳票データを帳票ＤＢ２２から取得する。より詳しくは、振分制御部２５は、習熟度が低い場合には、緊急度または重要度が高い帳票を避けて、帳票データを取得する。

そして、ステップＳ４０８で、サーバ２０の通信部２１は、振分制御部２５により取得された帳票イメージデータを、エントリ端末１０に返信する。

以上、本実施形態に係る振分け処理について説明した。

＜３．まとめ＞
以上説明したように、本発明の一実施形態に係るサーバ２０は、エントリ処理時間および未処理件数に基づくことで、繁忙時か閑散時かという時期的要因による格差を補正した、より正確な習熟度を算出することができる。さらに、サーバ２０は、帳票の取扱い金額および処理期限に基づくことで、重要度および緊急度という属性的要因による格差を補正した、より正確な習熟度を算出することができる。

また、サーバ２０は、算出した習熟度に基づいて、オペレータの業務スキルに合致したエントリ業務の振り分けを行うこともできる。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、上記実施形態では、金融機関における帳票のエントリ処理業務に関して習熟度の算出および振り分けを行う例を説明したが、本発明はかかる例に限定されない。例えば、あらゆる企業や工場などにおける、多数の定型作業を複数人に振り分ける処理に、本発明を適用してもよい。

また、情報処理装置に内蔵されるＣＰＵ、ＲＯＭ及びＲＡＭ等のハードウェアに、上記エントリ端末１０、サーバ２０、帳票読取端末３０の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記録した記録媒体も提供される。

１０ エントリ端末
１１ 通信部
１２ 制御部
１３ 表示部
１４ 操作部
１５ エントリ時間計測部
２０ サーバ
２１ 通信部
２２ 帳票ＤＢ
２３ 習熟度算出部
２４ オペレータ統計ＤＢ
２５ 振分制御部
３０ 帳票読取端末

Claims (12)

1. オペレータによる帳票のエントリ処理時間を取得する処理時間取得部と、
   帳票の未処理件数を取得する未処理件数取得部と、
   前記処理時間取得部により取得された前記エントリ処理時間、前記未処理件数取得部により取得された前記未処理件数、および前記オペレータの識別情報を対応付けて記憶する記憶部と、
   前記オペレータの習熟度を、前記識別情報と対応付けられて前記記憶部に記憶された前記エントリ処理時間および前記未処理件数に基づいて算出する算出部と、
   を備えるサーバ。
2. 前記算出部は、対応付けられた前記未処理件数が多いほど大きな重み付けを行って前記エントリ処理時間を加重平均した値に基づいて前記習熟度を算出する、請求項１に記載のサーバ。
3. 前記算出部は、閾値を超えている前記未処理件数に対応付けられた前記エントリ処理時間に基づいて前記習熟度を算出する、請求項１または２に記載のサーバ。
4. 前記記憶部は、前記帳票の取り扱い金額をさらに対応付けて記憶し、
   前記算出部は、対応付けられた前記取り扱い金額が高いほど大きな重み付けを行って前記エントリ処理時間を加重平均した値に基づいて前記習熟度を算出する、請求項１〜３のいずれか一項に記載のサーバ。
5. 前記記憶部は、前記帳票の処理期限をさらに対応付けて記憶し、
   前記算出部は、対応付けられた前記処理期限が短いほど大きな重み付けを行って前記エントリ処理時間を加重平均した値に基づいて前記習熟度を算出する、請求項１〜４のいずれか一項に記載のサーバ。
6. 前記未処理件数は、前記オペレータひとり当たりの件数である、請求項１〜５のいずれか一項に記載のサーバ。
7. 前記サーバは、前記算出部により算出された前記習熟度に基づいて、前記オペレータに新たな前記帳票のエントリ処理業務を振り分ける振分部をさらに備える、請求項１〜６のいずれか一項に記載のサーバ。
8. 前記振分部は、新たな前記帳票の取り扱い金額および処理期限にさらに基づいて、前記エントリ処理業務を振り分ける、請求項７に記載のサーバ。
9. 前記処理時間取得部は、前記オペレータにより操作されるエントリ端末により計測された前記エントリ処理時間を取得する、請求項１〜８のいずれか一項に記載のサーバ。
10. 前記未処理件数取得部は、前記オペレータが前記帳票をエントリ処理した際の前記未処理件数を取得する、請求項１〜９のいずれか一項に記載のサーバ。
11. オペレータによる帳票のエントリ処理時間を取得するステップと、
    帳票の未処理件数を取得するステップと、
    取得された前記エントリ処理時間、および前記未処理件数を、前記オペレータの識別情報に対応付けて記憶するステップと、
    前記オペレータの習熟度を、前記識別情報と対応付けられて記憶された前記エントリ処理時間および前記未処理件数に基づいて算出するステップと、
    を備える習熟度算出方法。
12. コンピュータに、
    オペレータによる帳票のエントリ処理時間を取得するステップと、
    帳票の未処理件数を取得するステップと、
    取得された前記エントリ処理時間、および前記未処理件数を、前記オペレータの識別情報に対応付けて記憶するステップと、
    前記オペレータの習熟度を、前記識別情報と対応付けられて記憶された前記エントリ処理時間および前記未処理件数に基づいて算出するステップと、
    を実行させるためのプログラム。
    

Images