(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0024】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0025】
<1.本発明の一実施形態に係るイメージエントリシステムの概要>
まず、
図1を参照して、本発明の一実施形態に係るイメージエントリシステムの概要について説明する。
【0026】
図1は、本発明の一実施形態に係るイメージエントリシステムの概要を示す説明図である。
図1に示すように、本発明の一実施形態に係るイメージエントリシステムは、帳票読取端末30、サーバ20、および複数のエントリ端末10を有し、それぞれネットワークにより接続されている。
【0027】
(帳票読取端末30)
帳票読取端末30は、帳票をスキャナにより読み取って、帳票のイメージデータを生成する装置である。帳票読取端末30は、読み取って生成した帳票イメージを示すデータ(以下、帳票イメージデータとも称する)を、サーバ20に送信する。
【0028】
(エントリ端末10)
エントリ端末10は、オペレータ操作によりエントリ処理業務を行う端末である。エントリ端末10は、帳票イメージデータを表示すると共に、オペレータによるデータ入力(以下、エントリ処理とも称する)を受け付ける。エントリ端末10は、処理対象である帳票イメージデータをサーバ20から受信して、エントリ処理を終えたデータ(以下、エントリデータとも称する)をサーバ20に返信する。
【0029】
(サーバ20)
サーバ20は、エントリ処理対象の帳票イメージデータを、オペレータの習熟度に応じて振り分ける機能を有する。具体的には、サーバ20は、格納処理、取得処理、統計処理、振分け処理を行う。格納処理とは、サーバ20が、帳票読取端末30により生成された帳票イメージデータを記憶する処理である。取得処理とは、サーバ20が、エントリ端末10を操作するオペレータがエントリ処理に要する時間(エントリ処理時間)を取得する処理である。統計処理とは、サーバ20が、オペレータの習熟度を算出する処理である。振分け処理とは、サーバ20が、習熟度に基づいてオペレータにエントリ処理対象の帳票イメージデータを振り分ける処理である。
【0030】
ここで、上述したように、上記特許文献では、オペレータの習熟度を処理時間から自動的に算出する技術が開示されている。しかしながら、時期や時間帯によって仕事量に大きな変動がある場合、エントリ処理時間に繁閑格差があるため、単にエントリ処理時間に基づくだけでは、オペレータの習熟度を正確に算出することが困難であるという問題があった。
【0031】
金融機関のエントリ業務においては、月末がピーク日であり、ピーク日には通常日の約3倍もの処理件数が発生する場合がある。また、ゴトウビと呼ばれる5の倍数の日にはピーク日の半分程度ではあるが、通常日よりも多い処理件数が発生する場合がある。また、正午過ぎの時間帯に集中的に処理件数が発生する傾向もある。このように、金融機関のエントリ業務においては、時期や時間帯によって仕事量に大きな変動があるため、単にエントリ処理時間に基づくだけでは、オペレータの習熟度を正確に算出することが困難である。
【0032】
また、帳票には、当日に処理しなければならない緊急性を要するものや、数日間の内に処理すればよいもの、金額が大きく重要度が大きいものなど、多様な種類がある。緊急性や重要度などは、エントリ処理時間に影響を与え得る要因であるが、上記特許文献ではこのような要因については何ら考慮されていない。
【0033】
そこで、上記事情を一着眼点にして本発明の一実施形態に係るイメージエントリシステムを創作するに至った。本発明の一実施形態に係るイメージエントリシステムは、エントリ処理時間に影響を与える要因を加味することで、オペレータの習熟度をより正確に算出することができる。
【0034】
具体的には、本発明の一実施形態に係るサーバ20は、繁忙期や閑散期などの時期的要因、および緊急度や重要度などの帳票の属性に基づく属性的要因に基づいて、エントリ処理時間を加重平均する。サーバ20は、これらの要因に基づいた加重平均を行うことにより、例えば繁忙時には一生懸命をエントリ処理し、逆に閑散時にはゆっくりエントリ処理する傾向によって生じる繁閑格差を補正することができる。属性的要因についても同様である。
【0035】
そして、サーバ20は、加重平均したエントリ処理時間に基づいて、オペレータの習熟度を算出する。習熟度は、上述の通り時期的要因が属性的要因による格差が補正されたエントリ処理時間に基づいて算出されるため、オペレータの業務スキルをより正確に反映している。
【0036】
さらに、サーバ20は、このようにして算出した習熟度に基づいて、各オペレータに対して帳票イメージデータを振り分ける。
【0037】
以上、本発明に一実施形態に係るイメージエントリシステムの概要について説明した。続いて、イメージエントリシステムの詳細な構成および動作処理について、
図2〜
図9を参照して説明する。
【0038】
<2.実施形態>
まず、
図2および
図3を参照して、エントリ端末10およびサーバ20の内部構成について説明する。
【0039】
[2−1.エントリ端末の構成]
図2は、本発明の一実施形態に係るエントリ端末10の構成を示すブロック図である。
図2に示すように、エントリ端末10は、通信部11、制御部12、表示部13、操作部14、およびエントリ時間計測部15を有する。
【0040】
(通信部11)
通信部11は、有線/無線により外部の情報装置との間でデータの送受信を行うための通信モジュールである。例えば、通信部11は、LAN(Local Area Network)や電話回線などに接続され、サーバ20と通信する。
【0041】
本実施形態では、通信部11は、帳票イメージデータの振り分け要求をサーバ20に送信して、サーバ20から振り分けられた帳票イメージデータを受信する。通信部11は、受信した帳票イメージデータを制御部12に出力する。ここで、振り分け要求には、エントリ端末10を操作するオペレータを識別するための識別情報が含まれている。また、通信部11は、制御部12から出力されたエントリデータ、およびエントリ時間計測部15から出力されたエントリ処理時間をサーバ20に返信する。
【0042】
(制御部12)
制御部12は、演算処理装置および制御装置として機能し、各種プログラムに従ってエントリ端末10内の動作全般を制御する。制御部12は、例えばCPU(Central Processing Unit)、マイクロプロセッサによって実現される。なお、制御部12は、使用するプログラムや演算パラメータ等を記憶するROM(Read Only Memory)、および適宜変化するパラメータ等を一時記憶するRAM(Random Access Memory)を含んでいてもよい。
【0043】
本実施形態では、制御部12は、通信部11から出力された帳票イメージデータを表示するよう、表示部13を制御する。また、制御部12は、操作部14により受け付けられたオペレータからの入力情報に基づいてエントリ処理を実行して、エントリデータを生成する。そして、制御部12は、生成したエントリデータを通信部11に出力する。また、制御部12は、表示部13が帳票イメージデータを表示したことを示す情報、およびその帳票イメージデータについてのエントリ処理が終了したことを示す情報を、エントリ時間計測部15に出力する。
【0044】
(表示部13)
表示部13は、制御部12による制御に基づいて、画像データ(静止画像/動画像)の表示を行う。表示部13は、例えばLCD(Liquid Crystal Display)またはOLED(Organic Light−Emitting Diode)、などにより実現される。
【0045】
本実施形態では、表示部13は、サーバ20により振り分けられた帳票イメージデータを表示する。より詳しくは、表示部13は、通信部11によりサーバ20から受信された帳票イメージデータを、制御部12による制御に基づき表示する。
【0046】
(操作部14)
操作部14は、オペレータによる操作に基づいて入力情報を受け付ける機能を有する。例えば、操作部14は、キーボード、マウス等により実現される。
【0047】
本実施形態では、操作部14は、オペレータによる帳票のエントリ処理を受け付ける。より具体的には、操作部14は、表示部13により表示された帳票イメージデータに応じた、オペレータによるデータ入力を受け付ける。操作部14は、受け付けた入力情報を制御部12に出力する。
【0048】
(エントリ時間計測部15)
エントリ時間計測部15は、オペレータによる帳票のエントリ処理時間を計測する機能を有する。具体的には、エントリ時間計測部15は、表示部13に帳票イメージデータが表示されてから、制御部12によるエントリ処理が終了するまで、即ちエントリデータが生成されるまでの時間を、エントリ処理時間として計測する。エントリ時間計測部15は、計測したエントリ処理時間を通信部11に出力する。
【0049】
以上、エントリ端末10の内部構成について説明した。
【0050】
[2−2.サーバの構成]
図3は、本発明の一実施形態に係るサーバ20の構成を示すブロック図である。
図3に示すように、サーバ20は、通信部21、帳票DB22、習熟度算出部23、オペレータ統計DB24、および振分制御部25を有する。
【0051】
(通信部21)
通信部21は、有線/無線により外部の情報装置との間でデータの送受信を行うための通信モジュールである。例えば、通信部21は、LANや電話回線などに接続され、エントリ端末10および帳票読取端末30と通信する。
【0052】
本実施形態では、通信部21は、エントリ端末10から帳票イメージデータの振り分け要求を受信する。そして、振り分け要求を振分制御部25に出力し、振分制御部25により振り分けられた帳票イメージデータを、エントリ端末10に返信する。また、通信部21は、エントリ端末10によりエントリ処理されたエントリデータおよびエントリ処理時間を受信して帳票DB22に出力する。ここで、通信部21を、エントリ端末10により計測されたオペレータによる帳票のエントリ処理時間を取得する、処理時間取得部としての機能を有すると捉えることができる。
【0053】
なお、通信部21は、帳票イメージデータをエントリ端末10に送信してから、エントリ端末10によりエントリ処理されたエントリデータを受信するまでにかかる時間を計測して、エントリ処理時間としてもよい。この場合、エントリ端末10がエントリ時間計測部15を有していない場合であっても、通信部21はエントリ処理時間を取得することができる。
【0054】
また、通信部21は、帳票読取端末30から帳票イメージデータを受信して、帳票DB22に出力する。
【0055】
(帳票DB22)
帳票DB22は、帳票に関する情報を記憶する記憶部としての機能を有する。帳票DB22は、通信部21により受信された各種情報に基づいて、新たに帳票に関する情報を追加したり、情報を更新したりする。ここで、
図4を参照して、帳票DB22が記憶する情報について説明する。
【0056】
図4は、本発明の一実施形態に係る帳票DB22が記憶する情報の一例を示す説明図である。
図4に示すように、帳票DB22は、1件の帳票について、帳票ID、処理日、受付日、帳票種別、帳票イメージデータ、オペレータID、エントリ処理時間、未処理件数、およびエントリデータを対応付けて記憶する。
【0057】
帳票IDとは、帳票を識別するための識別情報である。処理日とは、帳票がエントリ処理された日付を示す情報である。受付日とは、金融機関が顧客から帳票を受け付けた日付を示す情報である。帳票種別とは、帳票の種別を示す情報であり、一件式や連記式などがある。オペレータIDとは、オペレータを識別するための識別情報であり、その帳票をエントリ処理したオペレータを示している。未処理件数とは、オペレータが帳票をエントリ処理した際に、帳票DB22が記憶している帳票データのうち、エントリ処理がなされていない(未処理の)、エントリ処理待ちの帳票データの件数を示す情報である。
【0058】
通信部21により帳票読取端末30から帳票イメージデータが受信された場合、帳票DB22は、新しく帳票IDを生成して、受付日、帳票種別、および帳票イメージデータを対応付けて記憶する。ここで、受付日、帳票種別、および帳票イメージデータのみが記憶されている帳票データは、未処理である。
図4に示した例では、帳票IDが102または103の帳票データは未処理である。
【0059】
一方で、通信部21によりエントリ端末10からエントリデータおよびエントリ処理時間が受信された場合、帳票DB22は、処理日、エントリ処理したオペレータのオペレータID、未処理件数、エントリ処理時間、およびエントリデータを追加記憶する。つまり、受付日、帳票種別、および帳票イメージデータに加えて、処理日、オペレータID、エントリ処理時間、未処理件数、およびエントリデータが記憶されている帳票データは、エントリ処理済みである。
図4に示した例では、帳票IDが100または101の帳票データはエントリ処理済みである。
【0060】
帳票DB22は、帳票の未処理件数を取得する未処理件数取得部としての機能も有する。帳票DB22は、エントリ端末10においてオペレータがエントリ処理した際、例えばエントリ端末10への帳票イメージデータの送信時、またはエントリデータおよびエントリ処理時間の受信時に、未処理の帳票の総件数を取得する。そして、帳票DB22は、取得した総件数を未処理件数として記憶する。なお、帳票DB22は、総件数をオペレータの人数で割った、オペレータひとり当たりの件数を未処理件数として記憶してもよい。
【0061】
なお、
図4に示したデータはあくまで一例であり、本実施形態はかかる例に限定されない。例えば、帳票DB22は、帳票の取り扱い金額や処理期限をさらに対応付けて記憶してもよい。
【0062】
(習熟度算出部23)
習熟度算出部23は、オペレータの習熟度を、オペレータIDと対応付けられて帳票DB22に記憶された帳票データの、エントリ処理時間および未処理件数に基づいて算出する、算出部としての機能を有する。
【0063】
一般的に、オペレータの習熟度が高いほどエントリ処理時間は短く、低いほど長いと考えられる。しかし、上述したように、エントリ処理時間には繁閑格差があるため、単にエントリ処理時間に基づくだけではオペレータの習熟度を正確に測ることは困難である。ここで、繁忙時であるか閑散時であるかは、エントリ処理すべき帳票の多寡に現れると考えられる。即ち、繁忙時にエントリ処理された帳票に対応付けられた未処理件数は多く、逆に閑散時にはエントリ処理された帳票に対応付けられた未処理件数は少ないと考えられる。そこで、習熟度算出部23は、エントリ処理時間に加えて未処理件数にさらに基づいて習熟度を算出することで、オペレータの習熟度を正確に測ることができる。
【0064】
具体的には、習熟度算出部23は、対応付けられた未処理件数が多いほど大きな重み付けを行い、未処理件数が少ないほど小さな重み付けを行って、エントリ処理時間を加重平均した値に基づいて習熟度を算出する。ここで、繁忙時のエントリ処理時間は、オペレータが一生懸命であるためオペレータの習熟度が直接的に反映されやすいが、閑散時のエントリ処理時間は、習熟度が高いオペレータであってもゆっくり処理するため、習熟度が直接的に反映され辛い。つまり、未処理件数が多い時のエントリ処理時間はより確からしく、未処理件数が少ない時のエントリ処理時間はより確からしくない。このため、習熟度算出部23は、閑散時と比較してより確からしい繁忙時のエントリ処理時間により多く基づいて加重平均を行う。
【0065】
習熟度算出部23は、例えば次式により習熟度を算出する。
【0067】
なお、上記数式1におけるnは、対象期間における対象オペレータがエントリ処理した帳票の件数を示し、T
iは、i件目の帳票のエントリ処理時間を示し、N
iは、i件目の帳票をエントリ処理した際の未処理件数を示す。また、Avg(N)は、対象期間における単位時間当たりの未処理件数の平均を示す。数式1に示したように、習熟度は、エントリ処理時間T
iの逆数が大きいほど、即ちエントリ処理時間T
iが短いほど大きな値となる。また、数式1に示したように、習熟度は、未処理件数N
iが多いほど大きな重み付けを行って算出される。さらに、未処理件数N
iは平均の未処理件数Avg(N)により除算されるため、習熟度は、通常と比較して繁忙時のエントリ処理時間T
iに大きな重み付けを行い、通常と比較して閑散時のエントリ処理時間T
iに小さな重み付けを行って算出される。以下に、習熟度算出部23が習熟度を算出する具体例を説明する。
【0068】
例えば、4月のある日のある数分間において、オペレータAおよびBが、それぞれ2件の帳票をエントリ処理したものとする。4月の単位時間あたりの平均の未処理件数Avg(N)は100件であるものとする。この場合、未処理件数N
iが例えば200件であれば繁忙時であり、80件であれば閑散時である。
【0069】
このような状況において、オペレータAが、1件を未処理件数N
iが200件のときに40秒(T
i)でエントリ処理し、1件を未処理件数N
iが80件のときに100秒(T
i)でエントリ処理したものとする。この場合、オペレータAの習熟度は、上記数式1により、2.9×10
−2となる。一方で、オペレータBは、1件を未処理件数N
iが200件のときに50秒(T
i)でエントリ処理し、1件を未処理件数N
iが80件のときに80秒(T
i)でエントリ処理したものとする。この場合、オペレータBの習熟度は、上記数式1により、2.5×10
−2となる。
【0070】
オペレータAは2件を合計140秒で処理し、オペレータBは2件を合計130秒で処理しており、一見オペレータBの方が習熟度は高いとも思えるものの、算出される習熟度はオペレータAの方が高い。これは、オペレータAが、繁忙時においてはオペレータBよりも短いエントリ処理時間でエントリ処理しているからである。
【0071】
以上具体例において説明したように、習熟度算出部23は、繁忙時におけるエントリ処理時間により多く基づいて習熟度を算出する。このため、習熟度算出部23は、繁忙時か閑散時かという時期的要因による格差を補正した、より正確な習熟度を算出することができる。
【0072】
また、習熟度算出部23は、所定の閾値を超えている未処理件数に対応付けられたエントリ処理時間に基づいて前記習熟度を算出してもよい。習熟度算出部23は、繁忙時を示す閾値を設定することで、オペレータの習熟度が直接的に反映される繁忙時のエントリ処理時間のみに基づいた、より正確な習熟度を算出することができる。
【0073】
また、習熟度算出部23は、帳票の取り扱い金額が高いほど大きな重み付けを行ってエントリ処理時間を加重平均した値に基づいて習熟度を算出してもよい。さらに、習熟度算出部23は、帳票に設定された処理期限が短いほど大きな重み付けを行ってエントリ処理時間を加重平均した値に基づいて習熟度を算出してもよい。一般的に、取扱い金額が高いほど重要度が高く、当日処理など処理期限が短いほど緊急度が高い。そして、重要度が高いほど、緊急度が高いほどオペレータは一生懸命に処理するため、習熟度が直接的に反映されやすく、エントリ処理時間はより確からしい。習熟度算出部23は、取扱い金額が高いほど、処理期限が短いほど大きな重み付けを行って加重平均することで、重要度および緊急度という属性的要因による格差を補正した、より正確な習熟度を算出することができる。
【0074】
なお、上述したように、帳票DB22は、未処理の帳票データの総件数をオペレータの人数で割った、オペレータひとり当たりの件数を、未処理件数として記憶し得る。この場合、習熟度算出部23は、上記数式1にオペレータひとり当たりの件数を用いることで、オペレータの総人数に起因する繁閑格差を補正することができる。以下、オペレータの総人数に起因する繁閑格差について説明する。
【0075】
例えば、オペレータ数が10人である場合に、処理件数が5000件程度に達する時期は繁忙期であるとする。しかし、オペレータ数が仮に100人であれば、処理件数が5000件であっても繁忙期とは言い難い。また、処理件数が500件であっても、オペレータ数が1人であれば繁忙期といえる。習熟度算出部23は、未処理件数の総数に代えてオペレータひとり当たりの未処理件数を用いることで、このようなオペレータの人数に起因する繁閑格差を補正することができる。
【0076】
習熟度算出部23は、算出した習熟度をオペレータ統計DB24に出力する。
【0077】
(オペレータ統計DB24)
オペレータ統計DB24は、オペレータの属性情報を記憶する機能を有する。具体的には、オペレータ統計DB24は、属性情報のひとつとして、習熟度算出部23により算出された習熟度を記憶する。ここで、
図5を参照して、オペレータ統計DB24が記憶する情報について説明する。
【0078】
図5は、本発明の一実施形態に係るオペレータ統計DB24が記憶する情報の一例を示す説明図である。
図5に示すように、オペレータ統計DB24は、各オペレータについて、オペレータID、習熟度、およびその他の属性情報を対応付けて記憶する。
図5に示した例では、習熟度をアルファベットで表しており、Aが最も高い習熟度を表しており、B、C、Dになるにつれて徐々に低い習熟度を表している。
図5に示した例では、オペレータIDが003のオペレータの習熟度はAで最も高く、002のオペレータの習熟度はC、003のオペレータの習熟度はDとなっている。習熟度は、アルファベットの他にも、数値やその他の記号で表されてもよい。
【0079】
(振分制御部25)
振分制御部25は、習熟度算出部23により算出された習熟度に基づいて、オペレータに新たな帳票のエントリ処理業務を振り分ける振分部としての機能を有する。より具体的には、まず、振分制御部25は、通信部21により帳票イメージデータの振り分け要求が受信された場合に、送信元のエントリ端末10を操作するオペレータの習熟度をオペレータ統計DB24から取得する。そして、振分制御部25は、帳票DB22に記憶された未処理の帳票の中から、取得した習熟度に応じてひとつの帳票を選択し、選択した帳票を示す帳票イメージデータを通信部21に出力する。
【0080】
このとき、振分制御部25は、帳票の取り扱い金額および処理期限にさらに基づいて、エントリ処理業務を選択する。具体的には、振分制御部25は、習熟度が低いオペレータに対しては、緊急度または重要度が高い帳票を避けて、即ち処理期限が長く取扱い金額が低い帳票の帳票イメージデータを、振り分けるエントリ処理業務として選択する。このようにして、振分制御部25は、オペレータの習熟度に適する帳票を振り分けることができる。
【0081】
上述したように、振分制御部25が出力した帳票イメージデータは、通信部21により振り分け要求の送信元であるエントリ端末10に返信される。
【0082】
以上、エントリ端末10の内部構成について説明した。
【0083】
[2−3.動作処理]
続いて、本実施形態に係るイメージエントリシステムの動作処理について説明する。上述したように、本実施形態に係るイメージエントリシステムの動作処理は、格納処理、取得処理、統計処理、振分け処理に分けられる。以下、
図6〜
図9を参照して、これらの動作処理について順に説明する。
【0084】
(2−3−1.格納処理)
図6は、本発明の一実施形態に係る格納処理を示すフローチャートである。
図6に示すように、まず、ステップS102で、帳票読取端末30は、金融機関店舗で受け付けた帳票や、金融機関の事務センターに送られてきた帳票をスキャンして読み取る。
【0085】
次いで、ステップS104で、帳票読取端末30は、帳票を読み取って生成した帳票イメージデータを、サーバ20に送信する。
【0086】
そして、ステップS106で、サーバ20の帳票DB22は、通信部21により帳票読取端末30から受信された帳票イメージデータを記憶する。このとき、帳票DB22は、
図4に示したように、帳票ID、帳票イメージデータ、受付日および帳票種別を対応付けて記憶する。なお、帳票DB22は、帳票の取り扱い金額や処理期限をさらに対応付けて記憶してもよい。
【0087】
以上、本実施形態に係る格納処理について説明した。
【0088】
(2−3−2.取得処理)
図7は、本発明の一実施形態に係る取得処理を示すフローチャートである。
図7に示すように、まず、ステップS202で、サーバ20の通信部21は、帳票イメージデータをエントリ端末10に送信する。
【0089】
次いで、ステップS204で、エントリ端末10の表示部13は、通信部11によりサーバ20から受信された帳票イメージデータを表示する。次に、ステップS206で、エントリ時間計測部15は、エントリ処理時間の計測を開始する。次いで、ステップS208で、操作部14は、オペレータからのデータ入力を受け付け、制御部12はオペレータからの入力情報に基づいてエントリ処理を実行して、エントリデータを生成する。そして、ステップS210で、エントリ時間計測部15は、エントリ処理時間の計測を終了する。このようにして、エントリ時間計測部15は、表示部13に帳票イメージデータが表示されてから、制御部12によるエントリ処理が終了するまで、即ちエントリデータが生成されるまでの時間を、エントリ処理時間として計測する。
【0090】
次に、ステップS212で、エントリ端末10の通信部11は、制御部12により生成されたエントリデータ、およびエントリ時間計測部15により計測されたエントリ処理時間を、サーバ20に送信する。
【0091】
次いで、ステップS214で、帳票DB22は、帳票データの未処理件数を取得する。
【0092】
そして、ステップS216で、帳票DB22は、通信部21により受信されたエントリデータおよびエントリ処理時間、オペレータID、未処理件数、および処理日を、対応する帳票IDを有する帳票データに追加記憶する。
【0093】
以上、本実施形態に係る取得処理について説明した。
【0094】
(2−3−3.統計処理)
図8は、本発明の一実施形態に係る統計処理を示すフローチャートである。ここでは、ひとりのオペレータの習熟度を算出する処理について説明する。
図8に示すように、まず、ステップS302で、習熟度算出部23は、帳票DB22に格納されている、習熟度算出対象のオペレータを示すオペレータIDに対応付けられた情報を取得する。
【0095】
そして、ステップS304で、習熟度算出部23は、取得した情報に基づいて習熟度を算出する。より詳しくは、習熟度算出部23は、上記数式1を用いて、対応付けられた未処理件数が多いほど大きな重み付けを行い、未処理件数が少ないほど小さな重み付けを行って、エントリ処理時間を加重平均した値に基づいて習熟度を算出する。このとき、習熟度算出部23は、所定の閾値を超えている未処理件数に対応付けられたエントリ処理時間のみを用いてもよいし、取扱い金額が高いほど、処理期限が短いほど大きな重み付けを行って加重平均してもよい。
【0096】
次いで、ステップS306で、オペレータ統計DB24は、習熟度算出部23により算出された習熟度を、オペレータIDに対応付けて記憶する。
【0097】
次に、ステップS308で、習熟度算出部23は、統計処理を終了するか否かを判定する。統計処理を終了しない場合(S308/NO)、ステップS310で、処理は所定期間経過するまで中断して、ステップS302に戻る。このようにして、習熟度算出部23は、定期的/自動的に習熟度を算出および更新することができるため、人による管理負担が軽減される。一方で、統計処理を終了する場合(S308/YES)、処理は終了する。
【0098】
以上、本実施形態に係る統計処理について説明した。
【0099】
(2−3−4.振分け処理)
図9は、本発明の一実施形態に係る振分け処理を示すフローチャートである。
図9に示すように、まず、ステップS402で、エントリ端末10の通信部11は、帳票イメージデータの振り分け要求をサーバ20に送信する。
【0100】
次いで、ステップS404で、サーバ20の振分制御部25は、振り分け要求の送信元のエントリ端末10を操作しているオペレータのオペレータIDに対応付けられた習熟度を、オペレータ統計DB24から取得する。
【0101】
次に、ステップS406で、振分制御部25は、取得した習熟度に応じた未処理の帳票データを帳票DB22から取得する。より詳しくは、振分制御部25は、習熟度が低い場合には、緊急度または重要度が高い帳票を避けて、帳票データを取得する。
【0102】
そして、ステップS408で、サーバ20の通信部21は、振分制御部25により取得された帳票イメージデータを、エントリ端末10に返信する。
【0103】
以上、本実施形態に係る振分け処理について説明した。
【0104】
<3.まとめ>
以上説明したように、本発明の一実施形態に係るサーバ20は、エントリ処理時間および未処理件数に基づくことで、繁忙時か閑散時かという時期的要因による格差を補正した、より正確な習熟度を算出することができる。さらに、サーバ20は、帳票の取扱い金額および処理期限に基づくことで、重要度および緊急度という属性的要因による格差を補正した、より正確な習熟度を算出することができる。
【0105】
また、サーバ20は、算出した習熟度に基づいて、オペレータの業務スキルに合致したエントリ業務の振り分けを行うこともできる。
【0106】
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【0107】
例えば、上記実施形態では、金融機関における帳票のエントリ処理業務に関して習熟度の算出および振り分けを行う例を説明したが、本発明はかかる例に限定されない。例えば、あらゆる企業や工場などにおける、多数の定型作業を複数人に振り分ける処理に、本発明を適用してもよい。
【0108】
また、情報処理装置に内蔵されるCPU、ROM及びRAM等のハードウェアに、上記エントリ端末10、サーバ20、帳票読取端末30の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記録した記録媒体も提供される。