JP2013175088A - 依頼管理装置、依頼管理方法、プログラム、および依頼管理システム - Google Patents

Abstract

【課題】対象作業の依頼先の請負候補をより適確に選択する。
【解決手段】複数の請負候補の各々の処理能力を記憶する記憶部２２０と、作業量を含む依頼内容と、前記記憶部に記憶された前記複数の請負候補の各々の処理能力とを参照し、対象作業の依頼先の請負候補を選択する発注先選択部２４０とを備え、前記記憶部２２０は、前記複数の請負候補の各々への依頼状況をさらに記憶し、前記発注先選択部２４０は、前記複数の請負候補の各々への依頼状況、前記対象作業の作業量、および前記複数の請負候補の各々の処理能力を参照し、前記複数の請負候補のうちで、前記対象作業の納期前に前記対象作業を納品可能な請負候補を選択する。
【選択図】図６

Description

本発明は、依頼管理装置、依頼管理方法、プログラム、および依頼管理システムに関する。

近日、アウトソーシングを積極的に取り入れて業務を遂行する企業や機関が増加しつつある。例えば、企業や機関などの発注元は、アウトソーシングを行う場合、請負候補と連絡をとり、対象作業を受け入れ可能であることが確認された請負候補に新規作業を依頼する。

また、特許文献１には、各請負候補の作業進行状況、空き状況に応じて依頼先の請負候補を効率的に決定するためのシステムが開示されている。

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

しかし、上記のシステムでは、各請負候補の空き状況を発注元が把握できるものの、各請負候補の処理能力や対象作業の作業量は考慮されていない。このため、上記のシステムでは、対象作業を納期までに完了することが可能な請負候補を適確に選択することが困難であった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、対象作業の依頼先の請負候補をより適確に選択することが可能な、新規かつ改良された依頼管理装置、依頼管理方法、プログラム、および依頼管理システムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、複数の請負候補の各々の処理能力を記憶する記憶部と、作業量を含む依頼内容と、前記記憶部に記憶された前記複数の請負候補の各々の処理能力とを参照し、対象作業の依頼先の請負候補を選択する依頼先選択部と、を備える依頼管理装置が提供される。

前記記憶部は、前記複数の請負候補の各々への依頼状況をさらに記憶し、前記依頼先選択部は、前記複数の請負候補の各々への依頼状況、前記対象作業の作業量、および前記複数の請負候補の各々の処理能力を参照し、前記複数の請負候補のうちで、前記対象作業の納期前に前記対象作業を納品可能な請負候補を選択できるものとする。

前記記憶部は、前記複数の請負候補の各々との契約の内容をさらに記憶し、前記依頼先選択部は、前記複数の請負候補の各々との契約の内容をさらに参照して前記対象作業の依頼先の請負候補を選択できるものとする。

前記契約は、単位期間当たりの契約作業量についての契約を含み、前記依頼先選択部は、前記複数の請負候補のうちで、現期間における依頼済みの作業量と、前記契約作業量との差分が大きい請負候補を優先的に選択できるものとする。

前記契約は、緊急依頼の可否についての契約を含み、前記依頼先選択部は、前記対象作業の依頼が緊急依頼である場合、前記複数の請負候補の各々の緊急依頼の可否についての契約を参照して前記対象作業の依頼先の請負候補を選択できるものとする。

前記依頼管理装置は、前記複数の請負候補の各々について、依頼済み作業の完了予定時刻を算出する完了予定算出部をさらに備え、前記依頼先選択部は、前記完了予定算出部により算出された完了予定時刻が納期の後である依頼済み作業が存在する場合、当該依頼済み作業の少なくとも一部の再依頼先の請負候補を選択できるものとする。

前記完了予定算出部は、前記依頼済み作業の完了予定時刻を、前記請負候補の処理能力および前記依頼済み作業の進捗状況に基づく演算により算出できるものとする。

また、上記課題を解決するために、本発明の別の観点によれば、複数の請負候補の各々の処理能力を記憶媒体に記録するステップと、作業量を含む依頼内容と、前記複数の請負候補の各々の処理能力とを参照し、対象作業の依頼先の請負候補を選択するステップと、
を含む、依頼管理方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、複数の請負候補の各々の処理能力を記憶する記憶部と、作業量を含む依頼内容と、前記記憶部に記憶された前記複数の請負候補の各々の処理能力とを参照し、対象作業の依頼先の請負候補を選択する依頼先選択部と、として機能させるためのプログラムが提供される。

また、上記課題を解決するために、本発明の別の観点によれば、帳票を読取る読取装置、前記読取装置により読み取られた帳票を文字認識する文字認識装置、および、前記帳票のエントリ作業の依頼先を複数の請負候補から選択する依頼管理装置を備える依頼管理システムであって、前記依頼管理装置は、前記複数の請負候補の各々の処理能力を記憶する記憶部と、前記エントリ作業の作業量を含む依頼内容と、前記記憶部に記憶された前記複数の請負候補の各々の処理能力とを参照し、前記エントリ作業の依頼先の請負候補を選択する依頼先選択部と、を有する依頼管理システムが提供される。

以上説明したように本発明によれば、対象作業の依頼先の請負候補をより適確に選択することが可能である。

本実施形態によるインハウス型の依頼管理システムの構成を示した説明図である。 本実施形態による共同利用型の依頼管理システムの構成を示した説明図である。 本実施形態による依頼管理システムの全体動作を示したシーケンス図である。 依頼内容の入力画面の具体例を示した説明図である。 発注先の選択結果画面を示した説明図である。 発注先の選択結果画面を示した説明図である。 管理サーバの構成を示した機能ブロック図である。 実績記憶部が記憶する実績情報の具体例を示した説明図である。 契約記憶部が記憶する契約内容の具体例を示した説明図である。 発注状況記憶部が記憶する発注状況の具体例を示した説明図である。 発注先の選択アルゴリズムの具体例を示したフローチャートである。 進捗状況確認画面の具体例を示した説明図である。 再発注先の選択結果画面の具体例を示した説明図である。

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

また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。ただし、実質的に同一の機能構成を有する複数の構成要素の各々を特に区別する必要がない場合、同一符号のみを付する。

＜１．依頼管理システムの基本構成＞
本発明は、一例として以下に説明するような多様な形態で実施され得る。また、本発明の実施形態による管理サーバ２０は、請負候補の一例であるパンチ会社３０ごとの処理能力を記憶する記憶部２２０と、作業量を含む依頼内容と、記憶部２２０に記憶された複数のパンチ会社の各々の処理能力とを参照し、対象作業の発注先のパンチ会社を選択する発注先選択部２４０（依頼先選択部）と、を備え、依頼管理装置として機能する。

以下では、まず、このような管理サーバ２０を有する依頼管理システムの基本構成を説明する。なお、本実施形態による依頼管理システムは、多様な作業の依頼発注に適用することが可能であるが、以下では、依頼作業が帳票のエントリ作業であり、請負候補がパンチ会社３０である例を主に説明する。

（１−１．インハウス型のシステム構成）
図１は、本実施形態によるインハウス型の依頼管理システムの構成を示した説明図である。図１に示したように、インハウス型の依頼管理システムは、発注元会社に設けられるスキャンＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）１０、高速スキャナ１２、フラットヘッドスキャナ１３、ネットワークプリンタ１４、管理者ＰＣ１６、ネットワークＩＦ（インタフェース）１８、および管理サーバ２０と、複数のパンチ会社（Ａパンチ会社３０Ａ、Ｂパンチ会社３０Ｂ、Ｃパンチ会社３０Ｃ、・・・）と、を備える。

スキャンＰＣ１０は、高速スキャナ１２やフラットヘッドスキャナ１３などのスキャナと接続される。なお、用途に応じ、高速スキャナ１２のみがスキャンＰＣ１０に接続されてもよいし、フラットヘッドスキャナ１３のみがスキャンＰＣ１０に接続されてもよい。スキャンＰＣ１０は、高速スキャナ１２やフラットヘッドスキャナ１３などの接続されたスキャナを制御するＰＣであり、帳票のイメージ化、および帳票イメージの確認を行う際に用いられる。

高速スキャナ１２は、帳票の読取装置の一例であり、大量の帳票をイメージ化する際に用いられる。フラットヘッドスキャナ１３は、高速スキャナ１２と同様に帳票の読取装置の一例であり、少量のイメージを修正する際などに用いられる。ネットワークプリンタ１４は、多様な帳票を出力するための印刷装置である。

管理者ＰＣ１６は、パンチ会社３０へ発注する依頼内容の入力、パンチ会社の進捗の確認、納品物の確認などを行うための装置である。なお、スキャンＰＣ１０を管理者ＰＣ１６として用いることも可能である。

管理サーバ２０は、帳票イメージの管理や、パンチ会社３０の発注管理などを行う管理装置である。この管理サーバ２０については、「３．管理サーバの構成」以降で詳細に説明する。

ネットワークＩＦ１８は、ネットワーク８を介して各パンチ会社と通信を行う。例えば、ネットワークＩＦ１８は、帳票イメージをパンチ会社３０に送信し、パンチ会社３０によるエントリ作業の結果である戻りデータを受信する。

パンチ会社３０は、帳票のエントリ作業を行う会社である。各パンチ会社には、エントリ作業を行うためのエントリ端末、ベリファイ作業を行うためのベリファイ端末、および承認作業を行うための承認端末などが設けられる。

（１−２．共同利用型のシステム構成）
上記では、管理サーバ２０が発注元会社に設けられるインハウス型の依頼管理システムを説明したが、図２に示すように、管理サーバ２０を複数の発注元会社が共同で利用する共同利用型の依頼管理システムを実現することも可能である。すなわち、発注元会社＃１および発注元会社＃２などの各発注元会社にスキャンＰＣ１０、高速スキャナ１２、フラットヘッドスキャナ１３、およびネットワークプリンタ１４などを設置し、各発注元会社がネットワーク８を介して接続された管理サーバ２０を共同で利用することも可能である。

なお、図１および図２に示した各発注元会社内の各装置の数、パンチ会社３０の数、発注元会社の数は一例に過ぎず、本実施形態は図１および図２に示した例に限定されない。

＜２．依頼管理システムの全体動作＞
以上、本実施形態による依頼管理システムの基本構成を説明した。続いて、図３を参照し、本実施形態による依頼管理システムの全体動作を説明する。

図３は、本実施形態による依頼管理システムの全体動作を示したシーケンス図である。図３に示したように、本実施形態による依頼管理システムの動作は、データ入力業務、パンチ依頼、およびテキストデータ作成業務の３つの段階に大別される。

まず、高速スキャナ１２がスキャンにより帳票をイメージ化する（Ｓ１０２）。そして、スキャンＰＣ１０は、帳票イメージが入力されると（Ｓ１０４）、帳票イメージから帳票ＩＤを認識し、認識結果に応じた項目についてＯＣＲ認識を行う（Ｓ１０６）。その後、スキャンＰＣ１０のディスプレイ上でオペレータが帳票イメージを確認する（Ｓ１０８）。ここで、帳票が十分に読取れていない場合にはＳ１０２からの処理を繰り返す。

帳票イメージの確認後、スキャンＰＣ１０は帳票イメージを複数のイメージ（例えば、２つのイメージ）に分割する（Ｓ１１０）。このイメージ分割は、個人情報が含まれる帳票について行われる処理で、分割後の複数の帳票イメージを異なるパンチ会社に発注することにより個人情報が保護される。例えば、Ａパンチ会社３０Ａに氏名情報のエントリ作業を発注し、Ｂパンチ会社に住所や電話番号などのエントリ作業を発注すれば、個人の住所や電話番号の特定を防止することができる。なお、各帳票についてどのような分割を行うかを事前に設定しておくことで、スキャンＰＣ１０が自動的にイメージ分割を行うことが可能となる。

そして、スキャンＰＣ１０は、帳票イメージを管理サーバ２０に送信し（Ｓ１１２）、管理サーバ２０は、スキャンＰＣ１０から受信した帳票イメージを登録する（Ｓ１１４）。

その後、管理者が、管理者ＰＣ１６を用いて依頼内容を入力する（Ｓ１１６）。ここで、図４を参照し、依頼内容の入力画面について具体的に説明する。

図４は、依頼内容の入力画面の具体例を示した説明図である。図４に示したように、依頼内容の入力画面は、パンチ枚数の入力項目、納期の入力項目、イメージ分割の有無の入力項目、緊急依頼であるか否かの入力項目、納期厳守であるか否かの入力項目などを含む。管理者は、この入力画面において、依頼するパンチ枚数や納期などを指定する事が可能である

管理者ＰＣ１６は、このような入力画面において指定された依頼内容を管理サーバ２０に送信し（Ｓ１１８）、管理サーバ２０は、管理者ＰＣ１６から受信した依頼内容に基づいて発注先のパンチ会社を選択する（Ｓ１１８、Ｓ１２０）。なお、この発注先の選択については、「３．管理サーバの構成」以降で詳細に説明する。

続いて、管理者ＰＣ１６は、管理サーバ２０による発注先の選択結果を受信すると（Ｓ１２２）、管理者の指示に従ってパンチ会社への発注を行う。例えば、管理者ＰＣ１６は、図５Ａに示すように発注先の選択結果画面を表示し、管理者により「依頼ボタン」が操作されると、選択されたＡパンチ会社３０ＡおよびＢパンチ会社３０Ｂに発注を行う（Ｓ１２４Ａ、Ｓ１２６Ｂ）。一方、依頼内容の条件に合致するパンチ会社が見つからなかった場合、管理者ＰＣ１６は例えば図５Ｂに示すように例えば「該当するパンチ会社は見つかりませんでした。」というメッセージを含む結果画面を表示する。なお、管理者は、本発注に先立って発注先にメールや電話などで発注の可否の確認をとってもよい。

その後、Ａパンチ会社３０ＡおよびＢパンチ会社３０Ｂでのエントリ作業が完了すると（Ｓ１２６Ａ、Ｓ１２６Ｂ）、管理サーバ２０は作業結果である戻りデータをＡパンチ会社３０ＡおよびＢパンチ会社３０Ｂから受信する（Ｓ１２８Ａ、１２８Ｂ）。なお、各パンチ会社は、各帳票の作業結果を各帳票の作業完了時に送信してもよい。また、各パンチ会社の進捗を管理者ＰＣ１６で確認することも可能である（Ｓ１２７）。

その後、管理サーバ２０は、Ａパンチ会社３０ＡおよびＢパンチ会社３０Ｂから受信した作業結果を統合することにより最終的な納品物を完成させる（Ｓ１３０）。そして、管理者は、管理サーバ２０から供給される納品物のテキストデータを管理者ＰＣ１６のディスプレイ上で確認し、納品物を顧客に納品する（Ｓ１３２、Ｓ１３４）。

＜３．管理サーバの構成＞
以上、本実施形態による依頼管理システムの全体動作を説明した。本実施形態による依頼管理システムは、図３に示した「発注先の選択」の創意工夫により、対象作業の発注先を適確に選択することが可能である。以下、このような「発注先の選択」を行う管理サーバ２０の構成について詳細に説明する。

図６は、管理サーバ２０の構成を示した機能ブロック図である。図６に示したように、管理サーバ２０は、通信部２１０と、記憶部２２０と、データ管理部２３０と、発注先選択部２４０と、完了予定算出部２５０と、を備える。

（通信部）
通信部２１０は、管理者ＰＣ１６やパンチ会社３０とのインタフェースであって、管理者ＰＣ１６に発注先の選択結果や納品物などを送信する送信部、および、各パンチ会社３０から戻りデータなどを受信する受信部として機能する。

（記憶部）
記憶部２２０は、多様な情報、データを記憶する。この記憶部２２０は、例えば図６に示したように、スキャンＰＣ１０から送信される帳票イメージを記憶するイメージ記憶部２２１、各パンチ会社３０からの戻りデータを記憶する戻りデータ記憶部２２３、各パンチ会社３０の実績情報を記憶する実績記憶部２２５、各パンチ会社３０への発注状況を記憶する発注状況記憶部２２７、および各パンチ会社３０との契約の内容を記憶する契約記憶部２２９として機能する。以下、実績記憶部２２５が記憶する実績情報、発注状況記憶部２２７が記憶する発注状況、および契約記憶部２２９が記憶する契約の内容について図７〜図９を参照してより具体的に説明する。

図７は、実績記憶部２２５が記憶する実績情報の具体例を示した説明図である。図７に示したように、実績情報は、各パンチ会社の品質ランク、納期厳守ランク、過去の依頼における修正依頼件数、過去の依頼における納期遅れの有無、および処理能力などを含む。品質ランクは、例えば過去の依頼における修正依頼件数に基づいてデータ管理部２３０により設定され、納期厳守ランクは、例えば過去の依頼における納期遅れの有無に基づいてデータ管理部２３０により設定される。また、処理能力は、各パンチ会社の過去の量的な処理実績に基づいてデータ管理部２３０により設定される。

例えば、図７に示した実績情報によれば、Ａパンチ会社３０Ａは、過去の依頼における修正依頼件数が少ないので品質ランクが「Ａ」であり、過去の依頼における納期遅れが無いので納期厳守ランクも「Ａ」であり、処理能力が１００５枚／時である。なお、実績情報における各項目は実績の増加に応じて更新される。

図８は、契約記憶部２２９が記憶する契約内容の具体例を示した説明図である。図８に示したように、契約内容は、月間の発注件数、発注枚数、発注ロットの単位、および緊急パンチの発注可否などを含む。なお、緊急パンチは、通常より緊急度の高い依頼であり、緊急で処理しなければならないエントリ作業である。

例えば、図８に示した契約内容によれば、Ａパンチ会社３０Ａは、月間で「１０００枚×１００件以上」の発注件数、月間で「１０００００枚以上」の発注枚数、発注ロットの単位として「２００枚以上」、緊急パンチの発注「可」という内容で契約をしている。

図９は、発注状況記憶部２２７が記憶する発注状況の具体例を示した説明図である。図９に示したように、発注状況は、今月の発注枚数、現在仕掛中の案件、現在仕掛中の案件の納期、および進捗状況を記憶する。進捗状況は、各パンチ会社３０の管理者の手入力に基づいて設定されてもよい。また、共同利用型のシステムにおいては、各パンチ会社３０から１枚ごとの作業終了の都度に戻りデータが管理サーバ２０へ送信されるので、各戻りデータの受信に基づいてデータ管理部２３０が進捗状況を随時更新してもよい。

また、共同利用型のシステムにおいては、契約している会社間だけでなく、発注元および発注先を集約して管理することができる。すなわち、他社依頼分を含めて現在仕掛中案件を管理することができるので、各パンチ会社３０の状況をより正確に把握することが可能である。

（データ管理部）
ここで、図６を参照して管理サーバ２０の構成の説明に戻る。図６に示したデータ管理部２３０は、上述した記憶部２２０に記憶されているデータ、情報を管理する。例えば、データ管理部２３０は、実績情報や進捗状況を随時更新する。具体的には、データ管理部２３０は、各パンチ会社３０の過去の量的な処理実績に基づいて実績情報における処理能力を算出したり、各パンチ会社３０の進捗状況を設定したりする。なお、処理能力は、単位時間当たりの処理枚数の実績であってもよいし、単位時間当たりの入力項目数の実績であってもよい。

（発注先選択部）
発注先選択部２４０は、記憶部２２０を参照し、依頼内容に対して適切な発注先を選択する。発注先の選択アルゴリズムは特に限定されないが、図１０を参照し、発注先の選択アルゴリズムの一例を説明する。

図１０は、発注先の選択アルゴリズムの具体例を示したフローチャートである。図１０に示したように、発注先選択部２４０は、まず依頼内容を確認する（Ｓ３００）。

そして、発注先選択部２４０は、実績記憶部２２５や発注状況記憶部２２７を参照し、納期までに納品できるパンチ会社を抽出する（Ｓ３１０）。例えば、発注先選択部２４０は、各パンチ会社３０について、依頼枚数と処理能力を用いた演算により作業必要時間を算出し、現在仕掛中の案件の完了予定時刻から作業必要時間が経過した時刻が納期前であるパンチ会社３０を抽出する。なお、現在仕掛中の案件の完了予定時刻は、後述する完了予定算出部２５０により算出される。

続いて、発注先選択部２４０は、契約記憶部２２９を参照し、依頼内容が発注ロットの契約を満たすパンチ会社３０を抽出する（Ｓ３２０）。

その後、発注先選択部２４０は、Ｓ３１０およびＳ３２０の双方において抽出されたパンチ会社３０の数ｘと、発注先の必要数ｙとの関係を判断する（Ｓ３３０）。ここで、ｘとｙの関係が「ｘ＜ｙ」である場合、発注先選択部２４０はパンチ会社３０を選択せずに処理を終了する（Ｓ３４０）。一方、ｘとｙの関係が「ｘ＝ｙ」である場合、発注先選択部２４０はＳ３１０およびＳ３２０の双方において抽出されたパンチ会社３０を選択する（Ｓ３５０）。

また、ｘとｙの関係が「ｘ＞ｙ」である場合、発注先選択部２４０は、契約記憶部２２９を参照し、抽出されたパンチ会社３０のうちで月間の契約量が達成されていないパンチ会社３０を優先して選択する（Ｓ３６０）。ここで、発注先選択部２４０は、月間の契約量に対する未達成量（あるいは、未達成率）が大きいパンチ会社３０を優先して選択してもよい。

ここで、上述したアルゴリズムを以下に示す依頼内容の発注先選択に適用する場合を考える。なお、現在日時が２０１１年９月２０日１３：００であり、図７〜図９に示した実績情報、進捗状況および契約内容などが記憶部２２０に記憶されているものとする。
−依頼内容
・パンチ枚数 ：１０００枚
・納期 ：２０１１年９月２１日１８：００
・イメージ分割：有り
・依頼状況 ：通常
・納期厳守 ：絶対厳守

この場合、発注先選択部２４０は、Ｓ３１０において、各パンチ会社３０について、依頼枚数と処理能力を用いた演算により、作業必要時間を以下のように算出する。
−必要作業時間
・Ａパンチ会社：１０００／１００５≒１時間
・Ｂパンチ会社：１０００／５１０≒２時間
・Ｃパンチ会社：１０００／３５８≒３時間
・Ｄパンチ会社：１０００／７８≒１３時間

そして、発注先選択部２４０は、各パンチ会社３０について、現在仕掛中の案件の完了予定時刻から作業必要時間が経過した時刻を以下のように算出する。なお、Ａパンチ会社３０Ａの現在仕掛中の案件の完了予定時刻は９月２０日１４時、Ｂパンチ会社３０Ｂの現在仕掛中の案件の完了予定時刻は９月２０日１５時、Ｃパンチ会社３０Ｃの現在仕掛中の案件の完了予定時刻は９月２０日１４時、Ｄパンチ会社３０Ｄの現在仕掛中の案件の完了予定時刻は９月２０日１４時であり、営業時間は９時〜１７時であるものとする。
−納品可能時刻
・Ａパンチ会社：２０１１年９月２０日１５：００
・Ｂパンチ会社：２０１１年９月２０日１７：００
・Ｃパンチ会社：２０１１年９月２０日１７：００
・Ｄパンチ会社：２０１１年９月２２日１１：００

上記より、発注先選択部２４０は、納期である２０１１年９月２１日１８時までに納品可能なパンチ会社３０として、Ａパンチ会社３０Ａ、Ｂパンチ会社３０Ｂ、およびＣパンチ会社３０Ｃを抽出する。

続いて、発注先選択部２４０は、Ｓ３２０において、契約記憶部２２９を参照し、依頼内容が発注ロットの契約を満たすパンチ会社３０を抽出する。ここで、パンチ枚数１０００枚は、Ａパンチ会社３０Ａ、Ｂパンチ会社３０Ｂ、およびＣパンチ会社３０Ｃのいずれの発注ロットの契約も満たすので、発注先選択部２４０は、Ａパンチ会社３０Ａ、Ｂパンチ会社３０Ｂ、およびＣパンチ会社３０Ｃを抽出する。

ここで、イメージ分割に対応するために発注先の必要数ｙが「２」である場合、抽出されたパンチ会社３０の数ｘは「３」であるので、ｘとｙの関係は「ｘ＞ｙ」である。このため、発注先選択部２４０は、Ｓ３６０において、月間の契約量に対する未達成量（あるいは、未達成率）が大きいＡパンチ会社３０Ａ、おおびＢパンチ会社３０Ｂを優先して選択する。

（完了予定算出部）
図６に示した完了予定算出部２５０は、発注状況記憶部２２７が記憶する進捗状況に基づき、各パンチ会社３０について現在仕掛中の案件の完了予定時刻を算出する。例えば、完了予定算出部２５０は、進捗状況の示すパーセンテージから現在仕掛中の案件の残り枚数を算出し、残り枚数と処理能力を用いた演算により完了予定時刻を算出してもよい。

または、完了予定算出部２５０は、現在仕掛中の案件の処理ペースに基づいて完了予定時刻を算出してもよい。例えば、現在の進捗状況が６０％であり、現在仕掛中の案件の進捗が１０％進むのに２０分かかっていた場合、完了予定算出部２５０は、現時刻から８０分後を完了予定時刻として算出してもよい。

さらに、完了予定算出部２５０は、各パンチ会社３０のこれまでの作業の進め方を参照して完了予定時刻を算出してもよい。例えば、常に均等な処理ペースで作業を進めるパンチ会社もあれば、納期直前に処理ペースを上げるパンチ会社もあることが考えられる。そこで、完了予定算出部２５０は、パンチ会社３０ごとのこのような作業の進め方の相違を加味して完了予定時刻を算出してもよい。

＜４．再発注＞
以上説明したように、本発明の実施形態によれば、実績情報や契約内容などの多様な情報に基づいて発注先を適切に選択することが可能である。しかし、作業の発注後、パンチ会社３０の処理状況によっては納期遅れが生じ得る。このような事態に備えるために、本発明の実施形態による管理サーバ２０は、あるパンチ会社３０の納期遅れが生じそうな場合に、他のパンチ会社３０に作業を再発注するための機能も有する。以下、詳細に説明する。

管理サーバ２０の完了予定算出部２５０は、上述したように、発注状況記憶部２２７が記憶する進捗状況に基づき、各パンチ会社３０について現在仕掛中の案件の完了予定時刻を算出する。管理サーバ２０は、完了予定算出部２５０により算出された各パンチ会社３０について現在仕掛中の案件の完了予定時刻を含む進捗状況確認画面を生成し、管理者は、当該進捗状況確認画面を管理者ＰＣ１６において確認することができる。

図１１は、進捗状況確認画面の具体例を示した説明図である。図１１に示したように、進捗状況確認画面は、各パンチ会社３０についての現在仕掛中案件、現在仕掛中案件の納期、進捗状況および完了予定時刻を示す。ここで、Ｂパンチ会社３０Ｂの完了予定時刻が納期より後であるので、図１１に示したように、アラーム処理の一例としてＢパンチ会社３０Ｂの完了予定時刻は他と異なる色で強調表示される。

管理者は、この進捗状況確認画面を見ることで、遅延が発生しそうな状況を把握することができる。そして、管理者が進捗状況確認画面におけるパンチ会社再依頼ボタン７２を選択すると、管理サーバ２０の発注先選択部２４０がＢパンチ会社３０Ｂの仕掛中案件の少なくとも一部の再発注先を「３．管理サーバの構成」において説明したアルゴリズムに従って選択し、管理者ＰＣ１６が再発注先の選択結果を示す画面を表示する。

図１２は、再発注先の選択結果画面の具体例を示した説明図である。図１２には、納期遅延を生じさせずに作業を完了するために、再発注先としてＡパンチ会社３０Ａが選択され、再発注枚数として４２９枚が算出された例を示している。当該選択結果画面において管理者が依頼ボタン７４を選択することにより、Ａパンチ会社３０Ａへの再発注が行われる。

なお、上記では管理者が進捗状況確認画面を見ることで遅延が発生しそうな状況を把握する例を説明したが、本実施形態によるシステムは、納期遅延が発生しそうな場合には管理者画面にアラームを表示することにより管理者に状況を知らせることも可能である。

＜５．むすび＞
以上説明したように、本発明の実施形態によれば、依頼内容と実績情報や契約内容などの多様な情報に基づいて発注先を適切に選択することが可能である。また、納期遅延が発生しそうな場合には作業を他のパンチ会社３０に再発注することにより納期遅延の発生を防止することが可能である。

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

例えば、本明細書の依頼管理システム、管理サーバ２０の処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、管理サーバ２０の処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、管理サーバ２０や管理者ＰＣ１６に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアを、上述した管理サーバ２０や管理者ＰＣ１６の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供される。

８ ネットワーク
１０ スキャンＰＣ
１２ 高速スキャナ
１３ フラットヘッドスキャナ
１４ ネットワークプリンタ
１８ ネットワークＩＦ
２０ 管理サーバ
３０ パンチ会社
２１０ 通信部
２２０ 記憶部
２２１ イメージ記憶部
２２３ データ記憶部
２２５ 実績記憶部
２２７ 発注状況記憶部
２２９ 契約記憶部
２３０ データ管理部
２４０ 発注先選択部
２５０ 完了予定算出部

Claims (10)

1. 複数の請負候補の各々の処理能力を記憶する記憶部と、
   作業量を含む依頼内容と、前記記憶部に記憶された前記複数の請負候補の各々の処理能力とを参照し、対象作業の依頼先の請負候補を選択する依頼先選択部と、
   を備える、依頼管理装置。
2. 前記記憶部は、前記複数の請負候補の各々への依頼状況をさらに記憶し、
   前記依頼先選択部は、前記複数の請負候補の各々への依頼状況、前記対象作業の作業量、および前記複数の請負候補の各々の処理能力を参照し、前記複数の請負候補のうちで、前記対象作業の納期前に前記対象作業を納品可能な請負候補を選択する、請求項１に記載の依頼管理装置。
3. 前記記憶部は、前記複数の請負候補の各々との契約の内容をさらに記憶し、
   前記依頼先選択部は、前記複数の請負候補の各々との契約の内容をさらに参照して前記対象作業の依頼先の請負候補を選択する、請求項１に記載の依頼管理装置。
4. 前記契約は、単位期間当たりの契約作業量についての契約を含み、
   前記依頼先選択部は、前記複数の請負候補のうちで、現期間における依頼済みの作業量と、前記契約作業量との差分が大きい請負候補を優先的に選択する、請求項３に記載の依頼管理装置。
5. 前記契約は、緊急依頼の可否についての契約を含み、
   前記依頼先選択部は、前記対象作業の依頼が緊急依頼である場合、前記複数の請負候補の各々の緊急依頼の可否についての契約を参照して前記対象作業の依頼先の請負候補を選択する、請求項３または４に記載の依頼管理装置。
6. 前記依頼管理装置は、
   前記複数の請負候補の各々について、依頼済み作業の完了予定時刻を算出する完了予定算出部をさらに備え、
   前記依頼先選択部は、前記完了予定算出部により算出された完了予定時刻が納期の後である依頼済み作業が存在する場合、当該依頼済み作業の少なくとも一部の再依頼先の請負候補を選択する、請求項１〜５のいずれか一項に記載の依頼管理装置。
7. 前記完了予定算出部は、前記依頼済み作業の完了予定時刻を、前記請負候補の処理能力および前記依頼済み作業の進捗状況に基づく演算により算出する、請求項６に記載の依頼管理装置。
8. 複数の請負候補の各々の処理能力を記憶媒体に記録するステップと、
   作業量を含む依頼内容と、前記複数の請負候補の各々の処理能力とを参照し、対象作業の依頼先の請負候補を選択するステップと、
   を含む、依頼管理方法。
9. コンピュータを、
   複数の請負候補の各々の処理能力を記憶する記憶部と、
   作業量を含む依頼内容と、前記記憶部に記憶された前記複数の請負候補の各々の処理能力とを参照し、対象作業の依頼先の請負候補を選択する依頼先選択部と、
   として機能させるための、プログラム。
10. 帳票を読取る読取装置、前記読取装置により読み取られた帳票を文字認識する文字認識装置、および、前記帳票のエントリ作業の依頼先を複数の請負候補から選択する依頼管理装置を備える依頼管理システムであって、
    前記依頼管理装置は、
    前記複数の請負候補の各々の処理能力を記憶する記憶部と、
    前記エントリ作業の作業量を含む依頼内容と、前記記憶部に記憶された前記複数の請負候補の各々の処理能力とを参照し、前記エントリ作業の依頼先の請負候補を選択する依頼先選択部と、
    を有する、依頼管理システム。
    
    
    

Images