JP2022024177A - 印刷発注システム及びプログラム - Google Patents

Abstract

【課題】工用紙の供給元が用紙の発注を受け付けることを条件として発注元である工場に用紙を配送する場合とは異なり、用紙の種類別の使用量の管理を可能にする。【解決手段】工場に印刷を発注する印刷発注システムは、工場から収集される情報に基づいて、工場で使用された用紙の種類と使用された用紙の量を特定し、特定された用紙の種類と用紙の量を、使用された用紙の供給元に送信する。【選択図】図１０

Description

本発明は、印刷発注システム及びプログラムに関する。

現在、インターネットを通じて印刷の依頼を受け付け、指定された配送先に指定された期日に印刷物を納品するサービスが実用化されている。
このサービスを実現する手法には、印刷を受け付けた事業者が自社の印刷設備を用いて対応する手法、受け付けた依頼を提携する複数の印刷事業者に提供し、最初に受託を表明した印刷事業者に印刷を発注する手法などがある。
この他、特許文献１（特開２０１３－１６１５９号公報）には、インターネットを通じて印刷の依頼を受け付けた事業者が提携する印刷事業者の中から最適な一社を選択して発注するシステムが記載されている。

特開２０１３－１６１５９号公報

現在、事業として印刷物を印刷する印刷事業者は、製紙会社から買い取った用紙を工場内で保管し、例えば受注の見込みと用紙の在庫量とに基づいて、製紙会社に発注する用紙の数量を決定している。このように、印刷事業者における用紙の購入は印刷の受注に先立って行われており、見込み通りの受注が得られなかった場合、用紙の代金を回収できるまでの期間が長くなり、経営上の負担となる。このため、用紙の発注がギリギリになる傾向がある。一方、製紙会社には、受注の度に遅滞なく用紙を配送することが求められるが、用紙の受注が集中した場合、用紙の配送に用いるトラックの手配が難しくなる。また、製紙会社は計画的に用紙を製造するため、急な発注への対応が難しいことがある。
このため、印刷事業者と製紙会社の双方の利益に供するビジネスモデルが求められる。

本発明は、各工場が用紙の在庫を個別に管理して用紙の供給元に用紙を発注し、用紙の
発注を受け付けた用紙の供給元が個別に用紙を配送する場合とは異なり、用紙の種類別の使用量の管理を可能にすることを目的とする。

第１の発明は、工場に印刷を発注する印刷発注システムであって、工場から収集される情報に基づいて、工場で使用された用紙の種類と使用された用紙の量を特定し、特定された用紙の種類と用紙の量を、使用された用紙の供給元に送信する印刷発注システムである。
第２の発明は、特定された用紙の種類と用紙の量は、印刷の発注別、印刷ジョブ別、印刷装置別、工場別、又は、印刷を受注する事業者別に集計される、第１の発明に係る印刷発注システムである。
第３の発明は、特定された用紙の種類と用紙の量は、用紙を使用した工場又は印刷を受注した事業者に送信される、第１又は２の発明に係る印刷発注システムである。
第４の発明は、発注の履歴と、発注別に計算された用紙の使用量とに基づいて、用紙の需要量を予測し、予測された需要量を前記供給元に提供する、第１の発明に係る印刷発注システムである。
第５の発明は、前記用紙の需要量は、工場別、印刷を受注する事業者別、又は、用紙の供給元別に予想される、第４の発明に係る印刷発注システムである。
第６の発明は、工場毎に、用紙の種類別の残量を送信する、第４又は５の発明に係る印刷発注システムである。
第７の発明は、発注に対して、ユーザが希望する工場内の用紙の在庫が不足する場合でも、ユーザが定めた条件を満たすときには、当該工場に印刷を発注する、第１の発明に係る印刷発注システムである。
第８の発明は、ユーザが定めた前記条件は、予想される納期の遅延に関する範囲である、第７の発明に係る印刷発注システムである。
第９の発明は、工場に印刷を発注する印刷発注システムのコンピュータに、工場から収集される情報に基づいて、工場で使用された用紙の種類と使用された用紙の量を特定する機能と、特定された用紙の種類と用紙の量を、使用された用紙の供給元に送信する機能と、を実現させるプログラムである。

第１の発明によれば、各工場が用紙の在庫を個別に管理して用紙の供給元に用紙を発注し、用紙の発注を受け付けた用紙の供給元が個別に用紙を配送する場合とは異なり、用紙の種類別の使用量の管理を可能にできる。
第２の発明によれば、用紙の使用量の分析が容易になる。
第３の発明によれば、用紙を使用する工場と用紙の供給元とで情報を共有できる。
第４の発明によれば、需要量の予測の精度を高めることができる。
第５の発明によれば、供給元による用紙の計画的な生産や配送が可能になる。
第６の発明によれば、供給元による用紙の管理が容易になる。
第７の発明によれば、発注時に用紙が不足する場合にもユーザの希望する工場に発注される可能性を高めることができる。
第８の発明によれば、予想される納期の遅延がユーザの定めた条件を満たせば、ユーザの希望する工場に印刷を発注できる。
第９の発明によれば、工用紙の供給元が用紙の発注を受け付けることを条件として発注元である工場に用紙を配送する場合とは異なり、用紙の種類別の使用量の管理を可能にできる。

ネット印刷システムの例を概念的に説明する図である。 工場内の接続関係及び工場と印刷受発注サーバ等との接続関係の例を説明する図である。 印刷受発注サーバのハードウェア上の構成例を示す図である。 工場データベースに蓄積されるデータの一部を説明する図である。 用紙データベースに蓄積されるデータの一部を説明する図である。 予測需要データベースに蓄積されるデータの一部を説明する図である。 印刷受発注サーバの機能上の構成例を示す図である。 データ収集サーバのハードウェア上の構成例を示す図である。 データ収集サーバの機能上の構成例を示す図である。 工場内で発生する動的なデータの収集を説明する図である。 印刷オーダの受信から発注に伴うデータの流れを説明する図である。 印刷の発注後に発注先の工場で故障などのイベントが発生した場合の再発注を自動的に実行する例を説明する図である。 ダイレクトメールの印刷が依頼された場合における分散的な発注の例を説明する図である。 実施の形態２における発注先の決定方法を説明するフローチャートである。

以下、図面を参照して、本発明の実施の形態を説明する。

＜実施の形態１＞
＜システム全体の構成＞
本実施の形態に係るシステム全体の構成を図１及び図２を用いて説明する。
図１は、ネット印刷システム１の例を概念的に説明する図である。図２は、工場４００内の接続関係及び工場４００と印刷受発注サーバ３００等との接続関係の例を説明する図である。
なお、図１及び図２は概念図であり、実際の構成や接続関係は図１及び図２に示す内容に限らない。
ネット印刷システム１は、インターネット１００経由で印刷を依頼するユーザが操作するユーザ端末２００と、ユーザ端末２００から印刷の依頼を受け付ける印刷受発注サーバ３００と、製紙会社Ｐに設けられる用紙管理サーバ３５０と、印刷受発注サーバ３００から発注を受けた印刷を実行する工場４００とで構成される。

ユーザ端末２００は、印刷を依頼するユーザが操作するインターネット端末である。もっとも、印刷受発注サーバ３００による印刷の依頼の受付は、インターネット１００経由に限らない。例えばネット印刷システム１を通じて提供されるネット印刷サービスを提供する窓口事業者の従業員が、印刷受発注サーバ３００に接続された不図示の端末を操作して印刷の依頼を印刷受発注サーバ３００に入力してもよい。
本実施の形態の場合、ネット印刷システム１を構成する工場４００の全ては、１つの国又は地域に存在する必要はなく、複数の国又は地域に分散して存在してもよい。図１の場合、６つの工場４００は、日本とアメリカに分散して存在している。

本実施の形態において、工場４００とは、印刷物の生産に用いられる装置（以下「生産装置」ともいう。）が配置されている場所の意味で使用する。従って、工場４００は、生産装置が１台だけ配置されている印刷所や事業所も含む。
また、工場４００は、印刷専用の場所である必要はなく、区画の一部に生産装置が配置されている場所でもよい。例えば配送事業者、郵便事業者、電気事業者、ガス事業者、公益法人、医療事業者等の施設や事業所も、区画の一部に印刷物の生産装置が配置されていれば、本実施の形態における工場４００に含まれる。換言すると、印刷物の生産装置を配置していれば、事業者の業種は問わない。この意味で、配送事業者、郵便事業者、電気事業者、ガス事業者、公益法人、医療事業者等も印刷事業者に含まれる。

本実施の形態の場合、工場４００は、複数の印刷事業者が管理している。図１の場合、印刷事業者Ｗ、Ｘ、Ｙ、Ｚの４社である。これは、紙面の制約のためであり、実際には数の制約はない。なお、印刷事業者Ｗ、Ｘ、Ｙ、Ｚは、異なる法人である。また、印刷事業者Ｗ、Ｘ、Ｙ、Ｚは、資本関係や系列関係などの業務上の関係を有する必要はない。むしろ本実施の形態では、資本関係や系列関係などの業務上の関係を有しない印刷事業者Ｗ、Ｘ、Ｙ、Ｚを想定する。
なお、印刷事業者は工場４００を所有している必要はなく、印刷物を生産する生産装置を所有している必要もない。
また、本実施の形態の場合、印刷受発注サーバ３００に接続される工場４００の数は印刷事業者毎に異なってよい。
図１の場合、印刷事業者Ｗ、Ｘ、Ｚが接続する工場４００の数は１つであるが、印刷事業者Ｙが接続する工場４００の数は３つである。すなわち、各印刷事業者が印刷受発注サーバ３００に接続する工場４００の数は任意である。

本実施の形態の場合、工場４００には、印刷に関連する情報を収集して印刷受発注サーバ３００に登録するデータ収集サーバ５００と、印刷物を生産する印刷装置６００と、印刷物に加工を施す加工装置７００と、印刷のスケジュールを管理するワークフロー管理装置８００と、消耗品の在庫を管理する在庫管理装置９００と、印刷物の品質、工場内の環境、工場内の人の動き等を検知するセンサ１０００が配置されている。なお、工場４００には、生産装置を操作する人員の出勤等を管理する装置が配置されてもよい。
ここでの印刷装置６００と加工装置７００は、いずれも生産装置の一例である。図１の例では、印刷装置６００と加工装置の７００の両方が工場に配置されているが、いずれか一方だけが工場４００に配置されてもよい。換言すると、工場４００は、印刷専用の工場でもよいし、加工専用の工場でもよい。

また、ワークフロー管理装置８００は、生産管理装置の一例である。また、在庫管理装置９００は、在庫管理装置の一例である。
なお、本実施の形態では、印刷受発注サーバ３００と用紙管理サーバ３５０とデータ収集サーバ５００とで構成されるシステムを印刷受発注管理システムと呼ぶ。もっとも、印刷受発注サーバ３００とデータ収集サーバ５００とで構成されるシステム、又は、印刷受発注サーバ３００だけを印刷受発注管理システムと呼ぶこともある。
図１の場合、用紙管理サーバ３５０を１台だけ描いているが、これは作図上の制約によるものであり、配置される台数は任意である。なお、用紙管理サーバ３５０は、いわゆるサーバである必要はなく、業務に使用する端末であればよい。
また、図１の場合、用紙管理サーバ３５０は、製紙会社Ｐが管理しているが、勿論、製紙会社は複数でもよい。製紙会社が複数の場合、用紙管理サーバ３５０も複数である。なお、工場４００に用紙を供給する事業者は、製紙会社に限らず、卸問屋等でもよい。本実施の形態では、工場４００に用紙を供給する事業者を総称して「用紙の供給元」ともいう。

本実施の形態の場合、データ収集サーバ５００は、印刷受発注サーバ３００を運用する窓口事業者が各工場４００に設置する。
図１の場合、工場４００内には印刷装置６００を１台だけ描いているが、これは作図上の制約によるものであり、配置される台数は任意である。従って、工場４００に配置される印刷装置６００の台数は１台でもよいし、複数台でもよい。印刷装置６００の製造メーカは、工場４００毎に異なってもよい。また、工場４００内には、複数の製造メーカの印刷装置６００が混在してもよい。なお、印刷装置６００には、それぞれ専用の装置ＩＤ（＝IDentifier）が付されており、印刷ジョブの実行に関する情報や各装置の稼働に関する情報が１台毎に管理される。
加工装置７００についても、印刷装置６００と同様である。すなわち、加工装置７００は、工場４００内に１台に限る必要はなく、複数台でもよい。また、加工装置７００の製造メーカは、工場４００毎に異なってもよい。また、工場４００内には、複数の製造メーカの加工装置７００が混在してもよい。

ワークフロー管理装置８００は、工場内での生産を一括管理する装置である。例えばワークフロー管理装置８００は、印刷ジョブの受注処理、同じ仕様の印刷ジョブをまとめた面付け処理、印刷スケジュールや加工スケジュールの管理、印刷や加工の進捗管理、工場内で使用された用紙の量を管理する処理等を実行する。工場内で使用された用紙の量を管理する処理には、受注された印刷オーダ単位の管理、印刷ジョブ単位の管理、印刷事業者単位の管理を含めてもよい。受注された印刷オーダ単位の用紙の使用量や印刷ジョブ単位の用紙の使用量は、データ収集サーバ５００を通じて取得された印刷装置６００の動作の状況や動作の履歴、印刷スケジュール、用紙の交換や補充の記録等に基づいて計算される。本実施の形態の場合、用紙の使用量は、印刷装置６００から取得されるデータに基づいてリアルタイムで計算される。もっとも、リアルタイムの計算に限定されない。なお、用紙の使用量を管理する処理は、データ収集サーバ５００側で実行してもよい。
ワークフロー管理装置８００は、工場内のネットワークを通じて、印刷装置６００や加工装置７００と接続され、各種のデータを受け渡しする。例えば受信した印刷データ（原稿データ、版データを含む）は、印刷スケジュールに従って、ワークフロー管理装置８００から印刷装置６００に送信される。
本実施の形態におけるワークフロー管理装置８００は、(i) 用紙等が印刷の過程で搬送される経路上に配置され、印刷の不良や異常を検知するセンサ１０００からの出力データ、(ii)印刷物が加工の過程で搬送される経路上に配置され、加工の不良や異常を検知するセンサ１０００からの出力データ、(iii) 完成品としての印刷物の汚れや不良等の品質を管理するセンサ１０００からの出力データ等も管理する。

ここでのセンサ１０００は、印刷装置６００や加工装置７００の筐体内に配置されていてもよいし、印刷装置６００や加工装置７００とは別に配置されていてもよい。これらセンサ１０００から出力されるデータの形式は、センサ１０００の種類や製造メーカによって異なる。
また、本実施の形態におけるワークフロー管理装置８００は、生産された商品（加工を別工場で行う場合には加工前の印刷物）の納品に使用する配送サービス会社の情報も管理する。配送サービス会社の情報には、配送サービスを提供する事業者の名称、サービスの名称、配送サービスの詳細、出荷日、出荷番号、発注単位の請求額、発注元単位の総請求額、工場外での利用を禁止する情報を指定する情報等も管理する。
ワークフロー管理装置８００は、これらの情報の管理や機能の提供をコンピュータ上で動作するアプリケーションプログラムを通じて実現する。
また、センサ１０００は、作業員が作業に用いる機材に取り付けられていてもよい。

本実施の形態における在庫管理装置９００は、印刷装置６００で消費される用紙、インク、トナー、加工装置７００で消費されるフィルム等の部材の在庫に関する情報を管理する。なお、在庫に関する情報は、在庫を識別する符号（すなわち在庫ＩＤ）、部材の名称、部材のカテゴリ、在庫数、部材を供給する事業者を識別する符号（すなわちサプライヤＩＤ）、事業者の名称、事業者が供給する部材のタイプ等を含んでよい。
在庫に関する情報は、例えば在庫を識別する符号を部材の消費時に読み取ることにより更新される。また、在庫や在庫の包装に付されているＩＣタグに記録されている情報の読み取りにより更新される。

本実施の形態の場合、工場４００の敷地内や近隣の倉庫等に保管されている用紙は製紙会社の所有物である。すなわち、本実施の形態における印刷事業者は、印刷を受注する前に用紙を購入するのではなく、印刷後に使用した分の代金又は対価を支払うビジネスモデルを採用する。すなわち、従量課金を想定する。
なお、用紙の支払い方法はビジネス上の取り決めにより定まる。例えば用紙の代金を製紙会社に直接支払う方法に限らず、用紙の代金を控除した金額を、印刷の依頼主や印刷受発注サーバ３００を運営する事業者から受け取ることも可能である。もっとも、用紙の一部又は全部は、印刷の実績とは関係なく事前に購入されていてもよい。
本実施の形態の場合、印刷事業者が管理する在庫管理装置９００を用いて用紙の在庫を管理するが、在庫管理装置９００は製紙会社Ｐが管理してもよい。

データ収集サーバ５００は、印刷装置６００、加工装置７００、ワークフロー管理装置８００、在庫管理装置９００、センサ１０００と通信し、各装置から印刷に関する各種の情報を収集する。ここでの通信は、有線によっても無線によっても構わない。
データ収集サーバ５００は、例えば印刷装置６００から、装置を識別する符号（すなわち装置ＩＤ）、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、印刷の種類（タイプ）、印刷の速度、速度の単位、取扱可能な用紙の最大サイズと最小サイズ、色空間と色基準の情報、日次生産能力、受注した印刷オーダ又は印刷ジョブ毎に使用された用紙の種類、受注した印刷オーダ又は印刷ジョブ毎に使用された用紙の量等の情報を収集する。使用された用紙の量等は、例えば印刷装置６００等に設けられているセンサ１０００から取得されるデータに基づいて自動的に計算される。

ここでのステータスは、例えばアイドル状態、故障、使用中、メンテナンス中によって特定される。これらの情報の記述の形式は、印刷装置６００の製造メーカによって異なり、同じ製造メーカでも機種によって異なる場合がある。
受注された印刷オーダ又は印刷ジョブ毎に使用された用紙の種類や使用された用紙の量の情報には、供給元である製紙会社に関する情報が含まれる。なお、用紙の種類に関する情報には、カット紙、ロール紙等の分類、仕様、用途等が含まれる。ここで、印刷ジョブの管理ＩＤは、印刷オーダの管理ＩＤと紐付けられている。このため、印刷ジョブ毎に使用された用紙の情報は、印刷オーダに紐づけて管理される。なお、印刷中に発生する無駄紙も印刷ジョブに紐づけて管理される。
用紙がロール紙の場合、印刷ジョブ毎に使用された用紙の量は、印刷に使用された用紙の長さ、重さ、ロールの数等で特定される。また、用紙がカット紙の場合、印刷ジョブ毎に使用される用紙の量は、例えば枚数で特定される。なお、１枚の用紙に印刷オーダを異にする複数の版が割り付けられている場合には、印刷オーダ毎に換算された枚数等を用いることも可能である。これらの計算は、前述したように、ワークフロー管理装置８００等で実行してもよい。

また、データ収集サーバ５００は、例えば加工装置７００から、装置を識別する符号（すなわち装置ＩＤ）、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、加工の種類（タイプ）、加工の速度、速度の単位、日次生産能力等の情報を収集する。
ここでのステータスは、印刷装置６００の場合と同じである。また、加工の種類には、例えば折り加工、角丸加工、孔開け加工、ミシン加工、スジ入れ加工、表面加工、箔押し加工、パネル加工、型抜き加工等がある。これらの情報の記述の形式は、印刷装置６００の製造メーカによって異なり、同じ製造メーカでも機種によって異なる場合がある。

また、データ収集サーバ５００は、例えばワークフロー管理装置８００から、受注情報、印刷スケジュール、加工スケジュール、各スケジュールの進捗情報、各生産装置の稼働状況、各生産装置の稼働率、各生産装置のメンテナンス記録等の情報を取得する。
また、データ収集サーバ５００は、在庫管理装置９００から、生産装置で消費される消耗品の在庫に関する情報を収集する。本実施の形態の場合、消耗品の在庫に関する情報には、製紙会社別に用紙の種類毎の在庫の情報が含まれる。

データ収集サーバ５００は、各装置やセンサ１０００における情報の発生と同時に取得する。すなわち、本実施の形態におけるデータ収集サーバ５００は、工場内での生産に伴い発生し、時間とともに変化する情報を自動的に収集する。
また、本実施の形態におけるデータ収集サーバ５００は、収集した情報を機種の違いを問わない形式の情報に整備（クレンジング）する機能を備え、クレンジング後（整備後）の情報を印刷受発注サーバ３００に送信する。ここでの機種の違いには、製造メーカの違いが含まれる。
本実施の形態の場合、データ収集サーバ５００は、クレンジング後（整備後）の情報を分析した情報もセキュリティが確保された回線を通じて印刷受発注サーバ３００に送信する。クレンジング後（整備後）の情報を分析した情報も、機種の違いを問わない形式の情報の一例である。なお、クレンジング後（整備後）の情報を分析した情報には、例えば生産装置の現在時点での稼働空き状況、生産装置の将来時制での稼働空き状況の予測、在庫量の予測等が含まれてもよい。稼働空き状況の計算には、メンテナンスの予定や休日等も反映される。本実施の形態の場合、クレンジング（整備）の機能をデータ収集サーバ５００に設けているが、クレンジングは印刷受発注サーバ３００側で実行してもよい。この場合、印刷受発注サーバ３００は、フィルタ処理後の生データの一部を、セキュリティの確保された経路を通じて受信する。
本実施の形態の場合、印刷データは、印刷受発注サーバ３００からワークフロー管理装置８００に直接送信されているが、データ収集サーバ５００を経由してワークフロー管理装置８００に与えることも可能である。
なお、本実施の形態における印刷受発注サーバ３００は、単独で、又は、データ収集サーバ５００と協働で印刷発注システムを構成する。

＜各サーバの構成＞
＜印刷受発注サーバの構成＞
ここでは、印刷受発注サーバ３００の構成について説明する。
図３は、印刷受発注サーバ３００のハードウェア上の構成例を示す図である。
図３に示すように、印刷受発注サーバ３００は、プログラム（基本ソフトウェアを含む）の実行を通じて装置全体を制御するＣＰＵ（Central Processing Unit）３０１と、ＢＩＯＳ（Basic Input Output System）を記憶するＲＯＭ（Read Only Memory）３０２と、プログラムの実行領域として使用されるＲＡＭ（Random Access Memory）３０３とを有している。
ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３は、いわゆるコンピュータを構成し、各種の情報処理を実行する。なお、ＲＯＭ３０２は、例えば不揮発性の半導体メモリによって構成される。

ハードディスク装置（ＨＤＤ）３０４は、基本ソフトウェア、各工場４００のデータ収集サーバ５００からアップロードされた情報を解析するアプリケーションプログラム、ユーザが指定した印刷の条件を満たす工場４００を決定するアプリケーションプログラム、受注した印刷の依頼を管理する情報、各工場４００に関する情報等を記憶する。
本実施の形態では、情報の解析に人工知能を使用する。もっとも、予め定めた規則に従って情報を解析するアプリケーションプログラムでもよい。
受注した印刷の依頼を管理する情報には、例えば受注ＩＤ、依頼者に関する情報、依頼時に指定された条件、印刷データに関する情報、請求ＩＤ、請求に関する情報、受注した印刷の進捗状況等が含まれる。図３の場合、依頼者に関する情報は、依頼者データベース（依頼者ＤＢ）３０４Ａに記憶される。また、依頼時に指定された条件、請求に関する情報、受注した印刷の進捗状況等の情報は、依頼データベース（依頼ＤＢ）３０４Ｂに記憶される。依頼者データベース（依頼者ＤＢ）３０４Ａと依頼データベース（依頼ＤＢ）３０４Ｂは、ハードディスク装置３０４の記憶領域の一部に記憶される。

ここでの依頼者に関する情報には、例えば依頼者を識別する符号（すなわち顧客ＩＤ）、依頼者の名称、依頼者の居住地又は所在地、依頼者側の担当者に関する情報、依頼者の連絡先、依頼者の業種、顧客別に用意されたサービス上の管理番号、請求先の情報等が含まれる。
依頼時に指定された条件には、例えば希望の納期、希望の印刷事業者、希望の工場、印刷を実行する国又は地域、希望のアプリケーション、希望の金額、希望の配送方法、希望の用紙の種類、用紙の重量、希望の色プロファイル、希望の生産数量、仕上がりサイズ、片面又は両面印刷の指定、加工のタイプ、文書レイアウトのセクションの指定、製品の形態、単商品又は複数商品等を含む。ここでのアプリケーションは、例えばダイレクトメール、本等の印刷物の種別の指定に用いられる。
なお、製品の形態には、例えば書籍、ポストカード、ちらし、名刺、チケット、カタログ、伝票、封筒、シール、ラベル、袋、箱（パッケージ）等がある。
印刷データに関する情報には、例えば印刷データ、印刷データのファイルフォーマット等がある。

本実施の形態の場合、データ収集サーバ５００から受信される情報は、ハードディスク装置３０４の一部の記憶領域である工場データベース（工場ＤＢ）３０４Ｃに記憶される。工場データベース（工場ＤＢ）３０４Ｃは、蓄積手段及び蓄積装置の一例である。
本実施の形態の場合、工場データベース３０４Ｃには、データ収集サーバ５００からアップロードされる新たな情報が自動的に蓄積され更新される。
工場データベース３０４Ｃには、データ収集サーバ５００からアップロードされた情報に基づいて印刷受発注サーバ３００が算出する情報も記録される。
データ収集サーバ５００からアップロードされた情報に基づいて算出される情報には、例えば各工場の品質を評価した情報、各工場の過去の状態や現在の状況、過去の実績から計算される生産能力、予測されるスケジュール等が含まれる。
また、工場データベース３０４Ｃには、工場４００の所在地、営業日等の登録情報も記録される。ここでの登録情報は時間の経過に伴って変化しない、いわゆる静的な情報である。
また、工場データベース３０４Ｃには、印刷の依頼者であるユーザによる工場４００の評価、インターネット等を通じて受け付けた印刷をサービスに参加する工場４００に発注する事業者による工場４００の評価、過去の納期での遅延に関する記録、過去の納品に対して確認された品質の不良に関する記録等も記録される。

本実施の形態の場合、これらの情報の算出にも、人工知能を使用する。もっとも、予め定めた規則に従って情報を算出するアプリケーションプログラムを用いてもよい。
後述するように、データ収集サーバ５００は、新たなデータが発生するたび、又は、事象の変化が検知されるたび、それらの情報を印刷受発注サーバ３００にアップロードする。このため、工場データベース３０４Ｃの情報は、本実施の形態に係るネット印刷サービスに参加する工場４００の状況をリアルタイムで反映している。換言すると、工場データベース３０４Ｃの情報と工場４００内の状況は同期関係にある。

本実施の形態における工場データベース３０４Ｃには、印刷オーダや印刷ジョブで使用された用紙に関する情報も記憶される。
図４は、工場データベース３０４Ｃに蓄積されるデータの一部を説明する図である。（Ａ）は、実行済みの印刷ジョブと印刷に使用された用紙との関係を記録したテーブルＴ１であり、（Ｂ）は、印刷事業者Ｘの用紙別の総使用量を記録したテーブルＴ２である。
図４の場合、テーブルＴ１には、管理番号、印刷事業者ＩＤ、工場ＩＤ、印刷装置ＩＤ、印刷ジョブＩＤ、印刷オーダＩＤ、用紙ＩＤ、製紙会社ＩＤ、使用量等が記録される。用紙ＩＤは、使用された用紙の種類を特定できればよく、例えば製紙会社が使用するＩＤを用いる。
また、テーブルＴ２には、管理番号、対象期間、製紙会社ＩＤ、用紙ＩＤ、総使用量等が記録される。対象期間は、用紙別の総使用量を集計する期間である。図４の場合、対象期間は月単位で指定されている。もっとも、対象期間は、取引上の取り決めに従って指定が可能でもよい。

図３の例では、工場データベース３０４Ｃをハードディスク装置３０４に記憶しているが、工場データベース３０４Ｃは、クラウドサーバ上に記憶してもよい。
なお、クラウドサーバに記憶する場合、印刷受発注サーバ３００と工場データベース３０４Ｃとは同じ国又は地域に存在する必要はなく、異なる国又は地域に分散してもよい。
また、本実施の形態におけるハードディスク装置３０４には、印刷の依頼者が指定した条件を満たす発注先を決定する際に使用する受発注関係の学習済みモデル３０４Ｄが記憶されている。
学習済みモデル３０４Ｄは、工場データベース３０４Ｃで管理される工場４００の中から印刷の条件に適合する発注先を決定するための規則を与える。本実施の形態の場合、学習済みモデル３０４Ｄは、蓄積された受発注の記録、決定された依頼者による発注先に対する評価の登録や更新、印刷受発注サーバ３００内で計算される工場に対する評価の登録や更新等を学習する人工知能により常に更新される。

この他、ハードディスク装置３０４には、用紙データベース３０４Ｅと予測需要データベース３０４Ｆが記憶されている。
図５は、用紙データベース３０４Ｅに蓄積されるデータの一部を説明する図である。図５に示すテーブルには、管理番号、製紙会社ＩＤ、用紙ＩＤ、工場別在庫量、単価、特約等が記録される。単価は、使用量に応じた代金の計算に用いられる。

図６は、予測需要データベース３０４Ｆに蓄積されるデータの一部を説明する図である。（Ａ）は印刷事業者別の用紙の予測需要のテーブルＴ４を示し、（Ｂ）は製紙会社別の総予測需要のテーブルＴ５である。
図６の場合、テーブルＴ４には、管理番号、対象期間、製紙会社ＩＤ、用紙ＩＤ、予測需要等が記録される。印刷事業者別の予測需要は、依頼ＤＢ３０４Ｂ（図３参照）に記録されている取引の実績や工場ＤＢ３０４Ｃ（図３参照）に記録されている用紙の使用量等に基づいて、印刷受発注サーバ３００にインストールされているアプリケーションプログラムや人工知能により予測される。需要の予測であるので、対象期間には未来の日が入力される。図６の場合、半年後を想定しているが、１月後等でもよい。本実施の形態の場合、対象期間は、ユーザが指定する。もっとも、対象期間は、アプリケーションプログラムで定める既定値でもよい。テーブルＴ４には、印刷事業者が取引する製紙会社の情報が全て含まれる。また、図６の場合には、印刷事業者を単位としているが工場４００（図１参照）を単位とした予測需要を管理するテーブルが用意されてもよい。
また、テーブルＴ５には、管理番号、対象期間、用紙ＩＤ、総予測需要等が記録される。図６の場合には、製紙会社別の総予測需要であるが、製紙会社を問わない用紙の需要を予測したテーブルを用意してもよい。

この他、印刷受発注サーバ３００（図３参照）には、ＣＰＵ３０１（図３参照）で実行されるアプリケーションプログラムの操作画面の表示に用いられる表示部３０５（図３参照）、当該操作画面を操作する作業者の入力に用いられる操作入力部３０６（図３参照）、インターネット１００（図１参照）との通信に用いられる通信インタフェース（通信ＩＦ）３０７（図３参照）が設けられている。
ここでの表示部３０５及び操作入力部３０６は、印刷受発注サーバ３００の筐体に対して外付けされていてもよい。また、印刷受発注サーバ３００には、不図示の印刷装置が接続されていてもよい。
図３に示す各部は、不図示のバスや不図示の通信線を通じて互いに接続されている。

図７は、印刷受発注サーバ３００の機能上の構成例を示す図である。
図７に示す機能上の構成は、ＣＰＵ３０１（図３参照）によるプログラムの実行を通じて実現される。ここでの機能上の構成は、単一のプログラムに限らず、複数のプログラムの連携によって実現されてもよい。
機能面から見た印刷受発注サーバ３００は、印刷の依頼を受け付けるオーダ受付部３１１と、受け付けた依頼の条件に対して最適な発注先を自動的に決定する発注先決定部３１２と、決定された発注先である１つ又は複数の工場４００（図１参照）に対して印刷を発注する発注部３１３と、過去の受発注関係を学習して学習済みモデル３０４Ｄを更新する受発注関係学習部（ＡＩ）３１４と、工場データベース（工場ＤＢ）３０４Ｃに蓄積する分析データを計算する分析データ計算部３１５、分析データ計算部３１５で計算された用紙の使用量や予測需要等を印刷事業者や製紙会社等に提供する情報提供部３１６としての機能を有している。

オーダ受付部３１１は、Ｗｅｂサーバ等を通じて印刷の依頼を受け付ける受付手段の一例であり、受け付けた印刷の依頼を受注ＩＤによって管理する。オーダ受付部３１１は、依頼者データベース３０４Ａに依頼者に関する情報を登録し、又は、登録されている依頼者の情報を読み出す。
また、オーダ受付部３１１は、受け付けた依頼の条件等を依頼データベース３０４Ｂで管理する。依頼の条件には、印刷物を納品する場所、すなわち納品地の希望が含まれる。
また、納品地とは別に、印刷に使用する工場４００が存在する場所の希望が含まれてもよい。ここでの希望は、例えば国又は地域、国又は地域内の行政単位、行政単位の集合を表現する名称等で指定してもよい。なお、行政単位の階層的な構造や各階層の呼び方は国や地域によっても異なる。

発注先決定部３１２は、依頼の条件を満たす工場４００（図１参照）を発注先として決定する。発注先決定部３１２は、決定手段の一例である。発注先として決定される工場４００は、１つの依頼に対して１つの場合もあれば、１つの依頼に対して複数の場合もあり得る。本実施の形態の場合、依頼の条件に含まれる納品地に近い工場４００への発注を優先する。
発注先の決定には、工場データベース３０４Ｃと学習済みモデル３０４Ｄが用いられる。学習済みモデル３０４Ｄには、より適切な発注先を決定するためのモデルが記録されている。また、工場データベース３０４Ｃには、工場４００側と同期する情報（状態、生産能力、スケジュール）に加え、工場４００（図１参照）の品質に対する評価、過去の受発注の記録等が蓄積されている。ここでの評価は品質情報の一例である。

発注部３１３は、発注先に決定された工場４００（図１参照）に配置されているデータ収集サーバ５００に対して発注情報（例えば印刷のアプリケーション、加工の内容、部数、納品先、価格情報等）を送信するとともに、ワークフロー管理装置８００（図１参照）に対して印刷データを送信する。ここでの発注部３１３は、発注手段の一例である。また、発注情報は、発注データの一例である。前述したように、発注部３１３は、印刷データをデータ収集サーバ５００に送信してもよい。
本実施の形態における受発注関係学習部３１４は、人工知能（ＡＩ）の機能を用いて工場データベース３０４Ｃに記憶されている印刷の条件に対して決定された発注先、発注先としての工場を評価した情報等の関係を学習し、学習の成果を学習済みモデル３０４Ｄに反映する。
なお、工場データベース３０４Ｃに記憶されている情報は、機種の違いを問わない形式の情報に整備された後のデータ又はそれらを処理したデータであるので学習の精度が高まり易い。また、印刷受発注サーバ３００は、印刷を依頼する不特定のユーザと多数の印刷事業者との間の取引を中継するバブとして機能するので、取引の履歴や工場４００内における印刷の進行に関する情報を大量に収集できる。このため、学習の速度が上がり、同時に精度の向上も加速される。

分析データ計算部３１５は、各工場４００から自動的に工場データベース３０４Ｃに蓄積される生産装置の稼働の状態、生産能力、スケジュール等の情報に基づいて、各生産装置についての現在及び過去の稼働の状態、生産装置の将来時制での稼働空き状況の予測、将来の在庫量等を分析する。
また、分析データ計算部３１５は、各工場４００から自動的に工場データベース３０４Ｃに蓄積される印刷ジョブ毎に使用された用紙の種類や使用量に基づいて、各印刷事業者が製紙会社に支払う用紙の代金の計算も実行する。
また、分析データ計算部３１５は、過去の受発注の履歴や対応する用紙の使用量等の記録に基づいて将来の需要を予測する処理も実行する。予測された需要は、予測需要データベース３０４Ｆに記録される。
因みに、印刷受発注サーバ３００が印刷の依頼者から一括して料金を受領する場合には、分析データ計算部３１５が、印刷事業者や製紙会社に支払う金額を計算してもよい。
なお、データ収集サーバ５００（図１参照）で同等の分析処理が実行されている場合には、分析データ計算部３１５を設けなくてもよい。
情報提供部３１６は、ネット印刷システム１（図１参照）に参加する製紙会社に対して予測された需要を提供する他、印刷事業者が消費した用紙の量や代金の情報を製紙会社や印刷事業者に提供する。

＜管理サーバの構成＞
用紙管理サーバ３５０（図１参照）は、前述した印刷受発注サーバ３００と同様のハードウェア構成を有している。すなわち、用紙管理サーバ３５０は、プログラムの実行を通じて装置全体を制御するＣＰＵと、ＢＩＯＳ等を記憶するＲＯＭと、プログラムの実行領域として使用されるＲＡＭと、各種のプログラムや用紙の在庫情報や取引情報が記憶されるハードディスク装置と、各種の情報の表示に用いられる表示部と、作業者による操作の入力に用いられる操作入力部と、インターネット１００（図１参照）との通信に用いられるインタフェースとを有している。
用紙管理サーバ３５０は、インターネット１００を通じて接続された印刷受発注サーバ３００（図１参照）から、例えば印刷事業者が使用した自社の用紙の使用量や代金に関する情報、各工場に保管している自社の用紙の在庫の情報、印刷事業者別又は工場別の用紙の予測需要の情報等の通知を受ける。
なお、印刷事業者に請求する用紙の代金は、通知を受けた用紙の使用量に基づいて、用紙管理サーバ３５０が計算してもよい。

＜データ収集サーバの構成＞
次に、データ収集サーバ５００の構成について説明する。
図８は、データ収集サーバ５００のハードウェア上の構成例を示す図である。
図８に示すように、データ収集サーバ５００は、プログラム（基本ソフトウェアを含む）の実行を通じて装置全体を制御するＣＰＵ５０１と、ＢＩＯＳを記憶するＲＯＭ５０２と、プログラムの実行領域として使用されるＲＡＭ５０３とを有している。
ＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３は、いわゆるコンピュータを構成し、各種の情報処理を実行する。なお、ＲＯＭ５０２は、例えば不揮発性の半導体メモリによって構成される。

ハードディスク装置５０４は、基本ソフトウェア、印刷受発注サーバ３００から受信された発注情報、工場４００内から収集された生データが記憶される生データデータベース（生データＤＢ）５０４Ａ、生データを機種の違いを問わない形式の情報に整備（クレンジング）した後の生データが記録されるクレンジング済み生データデータベース（クレンジング済み生データＤＢ）５０４Ｂ、クレンジング済みの生データを分析した結果が記憶される分析結果データベース（分析結果ＤＢ）５０４Ｃ等を記憶する。
本実施の形態では、データ収集サーバ５００が、工場内から収集するデータを生データという。

印刷装置６００からは、製造メーカや機種に依存したデータ形式により、例えば装置ＩＤ、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、印刷の種類（タイプ）、印刷の速度、速度の単位、取扱可能な用紙の最大サイズと最小サイズ、色空間と色基準の情報、日次生産能力、印刷オーダや印刷ジョブ毎に使用された用紙の情報、印刷ジョブ毎に使用された用紙の量等の情報が工場内ネットワークを通じて自動的に収集される。
加工装置７００からは、製造メーカや機種に依存したデータ形式により、例えば装置ＩＤ、装置名、装置のスペック情報、装置のステータス、ステータスの詳細、加工の種類（タイプ）、加工の速度、速度の単位、日次生産能力等の情報が工場内ネットワークを通じて自動的に収集される。

ワークフロー管理装置８００からは、データを管理するアプリケーションプログラムに依存したデータ形式により、例えば受注情報、印刷スケジュール、スケジュールの進捗情報、各生産装置の稼働状況、各生産装置の稼働率、各生産装置のメンテナンス記録等の情報が工場内ネットワークを通じて自動的に収集される。
在庫管理装置９００からは、データを管理するアプリケーションプログラムに依存したデータ形式により、生産装置で消費される消耗品の在庫に関する情報が工場内ネットワークを通じて自動的に収集される。
また、不図示の検査装置等に搭載されるセンサ１０００からは、製造メーカや機種に依存したデータ形式により、各センサの出力がＩｏＴネットワーク等を通じて自動的に収集される。

本実施の形態の場合、分析結果データベース５０４Ｃには、例えば生産装置の現在時点での稼働空き状況、生産装置の将来時制での稼働空き状況の予測、在庫量の予測、生産装置の稼働スケジュール等が分析結果として記憶される。分析結果の内容やデータの形式は、工場４００の違いによらず統一した内容と形式で記録される。
なお、生データのクレンジング（整備）やクレンジング後（整備後）の生データの分析には、人工知能を使用してもよい。もっとも、予め定めた規則に従って情報を解析するアプリケーションプログラムを使用してもよい。

この他、データ収集サーバ５００には、ＣＰＵ５０１で実行されるアプリケーションプログラムの操作画面の表示に用いられる表示部５０５、当該操作画面を操作する作業者の入力に用いられる操作入力部５０６、インターネット１００や不図示の工場内ネットワークとの通信に用いられる通信インタフェース（通信ＩＦ）５０７が設けられている。
ここで、工場内ネットワークとの通信には、例えばＬＡＮ（Local Area Network）を使用する。工場内ネットワークとの通信に用いられる通信インタフェース５０７のうちデータの収集に用いられる通信部は、第１の通信手段の一例である。工場内ネットワークとの通信に用いられる通信インタフェース５０７のうち発注情報の送信に用いられる通信部は、第２の通信手段の一例である。
ここでの表示部５０５及び操作入力部５０６は、データ収集サーバ５００の筐体に対して外付けされていてもよい。
図８に示す各部は、不図示のバスや不図示の通信線を通じて互いに接続されている。

図９は、データ収集サーバ５００の機能上の構成例を示す図である。
図９に示す機能上の構成は、ＣＰＵ５０１（図８参照）によるプログラムの実行を通じて実現される。ここでの機能上の構成は、単一のプログラムに限らず、複数のプログラムの連携によって実現されてもよい。
機能面から見たデータ収集サーバ５００は、工場４００内の印刷装置６００、加工装置７００、ワークフロー管理装置８００、在庫管理装置９００、センサ１０００との通信により各装置やセンサから発注先の決定に使用される情報を生データとして収集する生データ収集部５１１と、収集された生データを機種の違いを問わない形式にクレンジング（整備）するクレンジング部５１２と、クレンジング済みの生データを分析して発注先の決定や各工場４００に固有の問題の改善に有用な情報を生成するデータ分析部５１３と、クレンジング済みの生データや分析結果を印刷受発注サーバ３００（図１参照）にアップロードするデータアップロード部５１４と、印刷受発注サーバ３００から発注情報を受信する発注情報受信部５１５としての機能を有している。

生データ収集部５１１は、工場内の生産装置等との通信により、生産装置等の状況、生産能力、スケジュール等を表す情報をリアルタイムで収集する。データの収集は、生データ収集部５１１による生産装置等への送信指示に対する応答として実現してもよいし、生産装置等から一方的に出力されるデータの受信によって実現してもよい。
収集の対象とするデータは、基本的に、時間の経過に伴って動的に変化する。もっとも、変化の周期はデータの種類によって異なる。
なお、生産装置等で発生又は管理される情報の全てを収集してもよいが、変化が検知された情報だけを選択的に収集してもよい。変化を検知する機能は、生データ収集部５１１に設けられてもよいし、生産装置等に設けられてもよい。

クレンジング部５１２は、製造メーカや機種等に依存するデータの形式等の違いを予め定めたデータの形式にクレンジング（整備）する。クレンジングでは、例えばデータフォーマットの変換だけでなく、表記の揺れや情報の重複が取り除かれる。クレンジング部５１２は、整備手段の一例である。
クレンジング部５１２は、作業員の個人情報の匿名化、印刷受発注サーバ３００（図１参照）への情報の提供を禁止する情報の除去等を実行してもよい。なお、印刷受発注サーバ３００へのアップロードは禁止するが、データ収集サーバ５００によるデータ分析での使用が許可されているデータについては、クレンジング部５１２が印刷受発注サーバ３００への送信を禁止するフラグ等を付した上でクレンジング（整備）を行ってもよい。

データ分析部５１３は、クレンジング後の生データを分析し、個々の生産装置又は工場全体での稼働率、生産装置の故障の予測、メンテナンスの予測、エラーパターンの予測、生産装置の状態、生産装置の生産能力、生産能力を向上させるスケジュール案、利益率を向上させるスケジュール案等を出力する。
データ分析部５１３は、分析の結果を表示部５０５（図５参照）の作業画面に表示する機能も備えている。

データアップロード部５１４は、クレンジング済みの生データやその分析結果を印刷受発注サーバ３００に自動的にアップロードする。
このうち、クレンジング済みの生データは、データ処理の後、遅滞なく自動的にアップロードされる。このアップロードにより、印刷受発注サーバ３００が発注先の決定に使用する工場データベース３０４Ｃ（図４参照）のデータと、アップロード元である工場４００（図１参照）内のデータとが同期される。
前述したように、印刷受発注サーバ３００へのアップロードが禁止されているデータは、アップロードの対象から除外される。本実施の形態の場合、データアップロード部５１４には、例えば予め定めた情報以外の情報がアップロードされないようにフィルタリングする機能が設けられている。
本実施の形態におけるデータアップロード部５１４は、通信内容の安全が保たれた状態で印刷受発注サーバ３００との通信を実行する。
発注情報受信部５１５は、印刷受発注サーバ３００からの発注情報の通知を受信する。
発注情報受信部５１５は、ワークフロー管理装置８００（図１参照）と連携し、発注情報の一部をワークフロー管理装置８００と共有する。

＜印刷受発注管理方法の例＞
以下では、ネット印刷システム１（図１参照）において実行される印刷受発注管理方法の例を説明する。
図１０は、工場４００内で発生する動的なデータの収集を説明する図である。
図１０には、工場４００内に存在するデータ収集サーバ５００で収集されたデータが、インターネット上に存在する印刷受発注サーバ３００に集約されるまでのデータの流れと対象期間内に集計された用紙の総使用量等が通知される様子を概念的に示している。
図１０における生産装置等は、印刷装置６００（図１参照）、加工装置７００（図１参照）、ワークフロー管理装置８００（図１参照）、在庫管理装置９００（図１参照）、センサ１０００（図１参照）である。

図１０の場合、生産装置等でデータの発生や変化を検知するイベントが発生すると、イベントに関する生データが生産装置等からデータ収集サーバ５００に自動的に送信される。ここでのイベントには、印刷装置６００への用紙の補充や交換、印刷ジョブの実行に伴い使用された用紙の量等の情報の更新、在庫管理装置９００で管理されている用紙の在庫量の更新等も含まれる。
データ収集サーバ５００は、受信した生データを蓄積した後、クレンジング（整備）し、更に分析して印刷受発注サーバ３００にアップロードする。印刷受発注サーバ３００は、新たに受信されたデータで蓄積データを更新する。

図中のアップロード＃１では、分析処理の実行後にアップロードを実行しているが、分析処理の実行前にクレンジング後の生データをアップロードしてもよい。アップロード＃２は、クレンジング（整備）後のデータを分析前にアップロードしている。なお、分析結果のアップロードは、アップロード＃２－１として別途実行される。
また、図１０では、イベント単位でアップロードを実行しているが、複数のイベントに対応する生データをまとめてアップロードしてもよい。
ただし、印刷受発注サーバ３００に蓄積されるデータと工場４００内のデータとを同期させる観点からは、イベントの発生からアップロードまでの時間は短いほど好ましい。

また、図１０に示すデータ収集サーバ５００は、対象期間内に使用された用紙の量の集計を更新すると、用紙の使用実績を用紙管理サーバ３５０及びデータ収集サーバ５００に通知する。図１０の場合、用紙の使用実績の通知は、蓄積データの更新回毎ではなく、予め定めた条件を満たすタイミングで実行している。このため、図中の３回目の更新回にのみ用紙の使用実績の通知が実行されている。もっとも、用紙の使用実績の通知は、蓄積データの更新回毎に実行してもよい。なお、予め定めた条件には、例えば対象期間の経過を用いてもよい。
また、図１０の場合には、印刷受発注サーバ３００で集計された用紙の使用実績を工場４００内のデータ収集サーバ５００に通知しているが、ワークフロー管理装置８００（図１参照）に通知してもよい。また、用紙の使用実績は、印刷事業者の本社等に設置されている不図示の管理端末に通知されてもよい。

本実施の形態の場合、印刷ジョブに関連付けて各種の情報が紐付けられて管理されるため、印刷ジョブ単位又は印刷オーダ単位による用紙の使用量、工場４００単位での用紙の使用量、印刷事業者単位での用紙の使用量等を、印刷受発注サーバ３００において正確に把握することができる。また、印刷受発注サーバ３００が、印刷事業者における用紙の正確な使用量を管理できることで、製紙会社は製造した用紙を工場４００の敷地内等に保管しておけば、工場４００内で使用された用紙の量に応じた金額を受け取ることができるようになる。また、印刷事業者においても、印刷を請け負う前に用紙を買い取る必要がなくなる。結果的に、用紙の従量課金が可能になる。換言すると、製紙会社と印刷事業者の双方に利益のあるビジネスモデルが実現される。

なお、用紙の種類毎の単価の情報が製紙会社から印刷受発注サーバ３００に提供されている場合には、使用量に応じた用紙の代金なども、印刷受発注サーバ３００から製紙会社と印刷事業者の双方に通知することが可能である。これらの情報を決裁システムに与えれば、当事者間の決裁も可能である。
また、図１０に示すデータ収集サーバ５００は、過去の受発注の履歴や工場４００から逐次通知される用紙の使用量や用紙の在庫等の情報に基づいて、将来の用紙の需要を予測し、予測された需要を製紙会社に通知する。通知される予測需要には、工場４００別の用紙の予測需要、印刷事業者別の用紙の予測需要、製紙会社別の予測需要等が含まれる。
本実施の形態における印刷受発注サーバ３００は、インターネットを使用して印刷を依頼する不特定のユーザとネット印刷システム１に参加する多数の印刷事業者との間の取引を中継するハブとして機能する。このため、印刷受発注サーバ３００には、受発注の記録だけでなく、個々の受発注に対して使用された用紙の量等も大量に蓄積されている。受発注の履歴が蓄積されるほど、将来の受発注の予測や用紙の需要の予測の精度が向上する。
このため、予測需要の通知を受ける製紙会社では、用紙を計画的に製造することができる。

図１１は、印刷オーダの受信から発注に伴うデータの流れを説明する図である。
図１２には、印刷受発注サーバ３００で印刷オーダが受信されてから発注先が決定されて、発注情報が工場４００側のデータ収集サーバ５００に送信されるまでのデータの流れを概念的に示している。工場データベース３０４Ｃ（図３参照）を参照して発注先を決定する。工場データベース３０４Ｃでは、工場４００内に配置された生産装置等の最新の情報が、機種の違いを問わない形式で管理されている。

図１１に示す印刷オーダ＃１の事例は、１つの工場４００Ａが発注先＃１に決定される場合に対応する。このため、発注＃１が工場４００Ａに配置されたデータ収集サーバ５００に送信されている。
なお、データ収集サーバ５００は、連携するワークフロー管理装置８００（図１参照）等に受信した発注情報を転送する。
図１１に示す印刷オーダ＃２の事例は、２つの工場４００Ａ及び４００Ｂが発注先＃２に決定される場合に対応する。１つの印刷オーダを複数の発注に分割する事例は、例えば１つの工場だけでは、印刷オーダで指定された印刷の条件を満たすことができない場合、後述するように納品先が複数の地域に分散している場合等に発生する。
図１１の例では、発注＃２Ａが工場４００Ａのデータ収集サーバ５００に送信され、発注＃２Ｂが工場４００Ｂのデータ収集サーバ５００に送信されている。

次に、印刷の発注後に発注先の工場で納期や品質に影響を及ぼす事象が発生した場合の動作について説明する。
従前のシステムの場合、ユーザから印刷の依頼を受け付ける事業者は、発注後に発注先の工場内部で納期や品質に影響する事象が発生しても、影響が確定して印刷事業者側から連絡を受けない限り知り得ない。また、知り得る場合でも、人手を介して情報が更新される分、対応が遅れてしまう。
図１２は、印刷の発注後に発注先の工場で故障などのイベントが発生した場合の再発注を自動的に実行する例を説明する図である。
図１２には、図１１との対応部分に対応する符号を付して示している。
図１２の場合も、印刷オーダ＃１を受信した印刷受発注サーバ３００は、発注先＃１として工場４００Ａを決定し、そのデータ収集サーバ５００に発注＃１を送信する点で、図１１の例と共通する。
勿論、データ収集サーバ５００は、受信した発注＃１をワークフロー管理装置８００（図１参照）等に転送し、印刷のスケジュールを更新する。

ここでは、発注＃１に対応する印刷のスケジュールが登録された後に、工場４００Ａ内の印刷装置６００（図１参照）や加工装置７００（図１参照）に故障などのイベントが発生した場合を想定する。
故障は、納期や品質に影響を及ぼす事象の一例である。なお、故障は、発注＃１に対応する印刷を開始する前に発生するかもしれないし、印刷の途中で発生するかもしれないし、印刷は終了しているが加工が開始する前に発生するかもしれないし、加工の途中で発生するかもしれない。
また、故障の発生は、発注＃１に対応する印刷が予定されている印刷装置６００で発生した場合や同じく加工が予定されている加工装置７００で発生した場合に限らない。印刷や加工が予定されている生産装置とは別の生産装置で故障が発生した場合でも、工場側の事情でスケジュール自体が変更され、その結果、発注＃１の納期や品質に影響が及ぶ可能性もある。
また、工場４００Ａが発注先＃１として決定された理由の１つに、技能が高い特定の作業員が勤務している時間帯での印刷等の実行が可能であることが含まれる場合、該当する作業員が発注＃１の印刷等の実行時に作業に従事しないことも、図１２で想定する故障などのイベントに含まれる。

いずれにしても、納期や品質に影響が及ぶ事象の発生は、データ収集サーバ５００が工場内から自動的に収集する生データの数値の変化として現れる。故障などの種類や内容によっては、センサ１０００（図１参照）によって直接検知される。
前述したように、データ収集サーバ５００は、収集された生データを即座にクレンジング（整備）し、クレンジング後（整備後）の生データ又は分析結果を自動的に印刷受発注サーバ３００にアップロードする。すなわち、自動アップロードする。
事象の発生から自動アップロードまでに人手が介在しないので、極めて短時間のうちに印刷受発注サーバ３００に情報が伝達される。
この自動アップロードにより、印刷受発注サーバ３００の工場データベース３０４Ｃ（図３参照）の蓄積データが更新される。
印刷受発注サーバ３００の発注先決定部３１２（図４参照）は、決定された発注先に印刷を発注した後も、工場データベース３０４Ｃの蓄積データを通じて、納期や品質に影響が及ぶ事象の発生を監視している。

図１２の場合には、故障などのイベントの影響が及ぶ印刷オーダ＃１について、その依頼の条件を満たす新しい発注先＃１を決定する。図１２では、工場４００Ｂが新しい発注先＃１である。
よって、印刷受発注サーバ３００は、工場４００Ｂのデータ収集サーバ５００に対して新しい発注＃１を送信する。この新しい発注＃１は、工場４００Ｂのデータ収集サーバ５００で受信され、ワークフロー管理装置８００（図１参照）等に転送される。
ここでの新しい発注＃１の内容は、工場４００Ａ内での印刷や加工の進捗の状況によって異なる。例えば工場４００Ａでの印刷が開始される前であれば、全ての印刷が新しく決定された工場４００Ｂに発注される。また例えば工場４００Ａでの印刷の一部が既に終了している場合には、残りの印刷と加工が新しく決定された工場４００Ｂに発注される。この場合も、工場４００Ａで使用された用紙の量の情報は、印刷受発注サーバ３００に送信され、課金の対象として記録される。
なお、印刷が既に開始している場合における残りの印刷の発注は、完全な意味での残りとするか、依頼していた印刷の全体を再発注するかは、予め定めた規則に基づいて決定する。
勿論、加工についても同様である。

図１２の場合、印刷受発注サーバ３００は、新しい発注＃１の送信後に、故障などのイベントが発生した工場４００Ａに対して発注＃１の取り消しを送信している。発注＃１が取り消されても使用された用紙の情報は、工場４００Ａに関連付けて記録される。
なお、工場４００Ａに対する発注＃１の取り消しの送信を、工場４００Ｂに対する新しい発注＃１の送信よりも前又は同時に実行してもよい。
発注＃１の取り消しを受信した工場４００Ａのデータ収集サーバ５００は、受信した発注＃１の取り消しをワークフロー管理装置８００等に転送し、印刷のスケジュール等を更新する。

図１３は、ダイレクトメールの印刷が依頼された場合における分散的な発注の例を説明する図である。
図１３には、図１との対応部分に対応する符号を付して示している。
ここでは、ユーザ端末２００の１つから宛先を１０００名とするダイレクトメールの印刷が印刷受発注サーバ３００に依頼されている。
印刷受発注サーバ３００は、例えばダイレクトメールを送付する宛先の情報に基づいて地域別の印刷オーダに分割する。図１３の例では、地域ＡＡに対応する１５０名分の印刷オーダと、地域ＢＢに対応する５００名分の印刷オーダと、地域ＣＣに対応する３００名分の印刷オーダと、地域ＤＤに対応する５０名分の印刷オーダに分割している。
因みに、地域ＡＡ、ＢＢ、ＣＣは日本であり、地域ＤＤはアメリカである。

図１３の場合、地域ＢＢに対応する５００名分の印刷オーダは、印刷事業者Ｙの工場１に対する４００名分の印刷オーダと、印刷事業者Ｚの工場１に対する１００名分の印刷オーダに更に分割される。
結果的に、印刷事業者Ｘには１５０名分の印刷オーダが発注され、印刷事業者Ｙには７００名分の印刷オーダが発注され、印刷事業者Ｚには１００名分の印刷オーダが発注され、印刷事業者Ｗには５０名分の印刷オーダが発注される。
ここで、印刷の条件を満たす１つの印刷事業者に発注する場合であれば、印刷事業者Ｙが発注先に決定されたかもしれないが、本実施の形態の場合には、送付先に近い工場に印刷オーダが分散されて発注される。この結果、印刷後の送付に要する時間や配送等に要する費用の削減が可能になる。

＜実施の形態２＞
続いて、実施の形態１で説明したネット印刷システム１（図１参照）を活用した他の実施の形態について説明する。
実施の形態１のネット印刷システム１を活用すると、依頼者の要求を満たすと同時に、印刷物の納品地に近い立地の１つ又は複数の工場４００（図１参照）に対して、発注を割り当てることも可能になる。ここでの要求には、特定の印刷事業者や工場の指定も含めることが可能である。
一方で、この仕組が実用化されると、窓口事業者が印刷の依頼を受け付けた時点における各工場４００の状況により発注の割り当て先が自動的に決定される。このため、印刷の依頼者が希望する印刷事業者や工場４００であっても、用紙の在庫が不足すれば、発注先の候補から一律に除外されてしまう。

ただし、該当する工場４００が用紙を補充するために発生する納期の遅れの日数や時間を依頼者が許容できる場合がある。
そこで、本実施の形態では、印刷の依頼者が希望する工場４００への発注が行えない理由が用紙の在庫の不足の場合でも、用紙の補充に伴う納期の遅れの予測が依頼者の定めた範囲内の場合には、他の工場４００ではなく、依頼者が希望した工場４００に優先的に発注できる機能を印刷受発注サーバ３００に設ける場合について説明する。
なお、基本的なシステム構成は、実施の形態１と同様であるため、以下では、本実施の形態に特有の処理手順について説明する。
図１４は、実施の形態２における発注先の決定方法を説明するフローチャートである。
なお、図中のＳはステップを意味する。
図１４に示す処理は、印刷受発注サーバ３００（図１参照）が、インターネット経由で印刷オーダを受信することで開始される。

ＣＰＵ３０１（図３参照）は、印刷オーダを受信すると、印刷オーダの依頼主を読み出す（ステップ１０１）。
次に、ＣＰＵ３０１は、読み出された依頼主の要求仕様に希望の工場の登録があるか否かを判定する（ステップ１０２）。依頼主の要求仕様は、印刷オーダに含まれていてもよいし、事前に依頼者データベース３０４Ａ（図７参照）に登録されていてもよい。本実施の形態の場合、要求仕様には、依頼者が印刷の発注先として希望する工場４００が優先順位付きで登録されている。以下では、優先順位が１位の工場４００をプライマリ工場、優先順位が２位の工場４００をセカンダリ工場ともいう。プライマリ工場やセカンダリ工場は、地域別に与えられてもよい。例えば地域ＡＡと地域ＢＢとでプライマリ工場やセカンダリ工場が異なってもよい。なお、希望の工場の登録数は３つ以上でもよい。
なお、要求仕様には、納期の遅れを許容する場合の日数や時間等も含まれる。
要求仕様に希望の工場の登録がない場合、ＣＰＵ３０１は、ステップ１０２で否定結果を得る。この場合、ＣＰＵ３０１は、印刷オーダを満たす工場を発注先に決定する（ステップ１０３）。このステップ１０３の処理は、実施の形態１で説明した処理と同じである。

要求仕様に希望の工場の登録がある場合、ＣＰＵ３０１は、ステップ１０２で肯定結果を得る。この場合、ＣＰＵ３０１は、依頼主が希望する工場を読み出す（ステップ１０４）。
まず、ＣＰＵ３０１は、優先順位が１位の工場の最新情報を取得する（ステップ１０５）。すなわち、ＣＰＵ３０１は、プライマリ工場の最新の情報を工場データベース３０４Ｃ（図４参照）から取得する。
次に、ＣＰＵ３０１は、プライマリ工場の用紙の在庫が印刷オーダの実行に十分か否かを判定する（ステップ１０６）。なお、図１４では、用紙の在庫が印刷オーダの実行に十分であれば、依頼者が指定した納期は満たすものと仮定している。例えば用紙の在庫は十分でも、印刷のスケジュールに空きがなければ納期内での印刷の完了は見込めないが、図１４では、用紙の在庫以外は印刷オーダを満たすものと仮定している。

説明を続ける。
用紙の在庫が印刷オーダを満たす場合、ＣＰＵ３０１は、ステップ１０６で肯定結果を得る。この場合、ＣＰＵ３０１は、プライマリ工場を発注先に決定する（ステップ１０７）。用紙の在庫が印刷オーダを満たすので、別の工場への発注を検討することなく、発注先の決定が確定する。
用紙の在庫が印刷オーダを満たさない場合、ＣＰＵ３０１は、用紙の補充に伴う納期の予想超過時間を計算する（ステップ１０８）。
予想超過時間は、製紙会社等から用紙の補充を受けた工場で発注された印刷が完了すると予想される時刻が、依頼者が指定した納期を超過する時間長として計算される。この計算には、用紙が製紙会社等から工場４００に配送されるまでの時間も含まれる。ＣＰＵ３０１は、印刷が完了する予想の時刻を、プライマリ工場から取得しているスケジュールに基づいて予測する。

次に、ＣＰＵ３０１は、超過時間が要求仕様を満たすか否かを判定する（ステップ１０９）。依頼主が指定した納期の超過時間が要求仕様を満たす場合、ＣＰＵ３０１は、ステップ１０９で肯定結果を得る。この場合、ＣＰＵ３０１は、製紙会社に用紙の補充を発注する（ステップ１１０）。用紙の発注先となる製紙会社は、プライマリ工場の過去の発注の履歴や登録情報に基づいて決定される。この後、ＣＰＵ３０１は、ステップ１０７に移動する。このように、用紙の在庫が不足する場合でも、用紙の補充に伴う納期の遅れが依頼主の定めた条件を満たす場合には、依頼者の希望を優先した発注が可能になる。この例の場合、用紙の配送先は、プライマリ工場である。
一方、ステップ１０８で計算された超過時間が要求仕様を満たさない場合、ＣＰＵ３０１は、ステップ１０９で否定結果を得る。この場合、ＣＰＵ３０１は、次の優先順位の工場があるか否かを判定する（ステップ１１１）。
ステップ１１１で否定結果が得られた場合、ＣＰＵ３０１は、依頼者の希望する工場への発注を断念し、ステップ１０３に移行する。

これに対し、ステップ１１１で肯定結果が得られた場合、ＣＰＵ３０１は、次の優先順位の工場の最新情報を取得する（ステップ１１２）。例えばセカンダリ工場についての最新情報が取得されると、ＣＰＵ３０１は、ステップ１０６に移動し、プライマリ工場と同様の処理を繰り返す。
すなわち、セカンダリ工場における用紙の在庫が印刷オーダの実行に十分である場合には、セカンダリ工場が発注先に決定される。また、セカンダリ工場における用紙の在庫が印刷オーダの実行に不足する場合でも、用紙の補充に伴う納期の超過が依頼主の定めた条件を満たす場合には、セカンダリ工場が発注先に決定される。
図１４の場合には、印刷オーダを１つの工場に発注する前提で説明されているが、１つの印刷オーダをプライマリ工場とセカンダリ工場に分割して発注することも可能である。
この場合、個々の工場では印刷オーダを満たす用紙の在庫がなくても、２つの工場の用紙の在庫を足し合わせれば印刷オーダを満たす可能性もある。そこで、ステップ１１１で否定結果が得られた場合には、プライマリ工場とセカンダリ工場の両方の在庫が印刷オーダの実行に十分か否かを判定してもよい。以下の動作は、単一の工場を対象とした処理動作と同じである。

＜他の実施形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は上述の実施の形態に記載の範囲に限定されない。上述の実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

例えば前述の実施の形態では、印刷や加工を行う印刷事業者の工場４００（図１参照）内に配置したデータ収集サーバ５００（図１参照）が工場４００内に配置された生産装置等で発生した又は管理される情報等を収集して印刷受発注サーバ３００にアップロードしているが、アップロードする情報に生産された印刷物の出荷スケジュールを含めてもよい。
また、データ収集サーバ５００を、工場４００からの印刷物の出荷や配送を請け負う各地域の配送事業者の事業所内に設け、集配スケジュールや配送に従事する従業員の出勤スケジュール等を収集し、印刷受発注サーバ３００（図１参照）にアップロードしてもよい。
この場合、印刷受発注サーバ３００は、工場４００からの出荷スケジュールや配送事業者の事業所毎の集配スケジュールも含め、印刷の発注先を決定することが可能になる。この例の場合、印刷受発注サーバ３００は、配送事業者についての遅延の履歴や評価の情報も管理する。

また、前述の実施の形態では、クレンジング（整備）をデータ収集サーバ５００（図１参照）で実行しているが、データ収集サーバ５００で収集された生データをセキュリティが確保された回線等を通じて印刷受発注サーバ３００（図１参照）に送信し、印刷受発注サーバ３００側でクレンジング（整備）を実行してもよい。クラウドサーバへの生データ等の送信には、クレンジング機能を有しないデータ収集サーバ５００を用いてもよいし、ワークフロー管理装置８００（図１参照）や不図示の端末装置を用いてもよい。
または、工場内で自動的に収集された生データを蓄積するクラウドサーバ上でクレンジング（整備）を実行し、クレンジング後のデータを印刷受発注サーバ３００に送信してもよい。ここでのクラウドサーバは、データ収集サーバ５００の一形態である。

前述の実施の形態では、印刷受発注サーバ３００で予測した用紙の需要を製紙会社Ｐに提供し、用紙の補充や配送を製紙会社Ｐの管理に委ねているが、予測された用紙の需要や各工場の用紙の在庫に基づいて、工場４００に対する用紙の補充や配送を、印刷の発注とは無関係に印刷受発注サーバ３００が手配してもよい。
この仕組の採用により、用紙の在庫不足を原因とする工場４００の受注機会の損失の減少、印刷物の納期遅れの発生の減少、納期遅れの期間の短縮等が可能になる。
また、用紙の在庫不足を原因として別の工場４００に印刷が発注されることで発生する追加の費用の抑制が可能になる。例えば製紙会社Ｐが受注した印刷の単位で用紙を発注する仕組みの場合には、印刷を発注する時点において、依頼者が指定した工場４００で用紙が不足し、かつ、特急処理等の要望を満たすために依頼者の指定とは異なる工場４００に印刷を発注されることがあり、依頼者が想定していない輸送料などの追加の費用が発生する可能性がある。また例えば印刷を発注する時点では、依頼者が指定した工場４００における用紙の在庫が印刷に対して十分でも、機械の故障や印刷ミス等に起因して用紙の無駄（いわゆるヤレ）が発生する場合には、不足する用紙の調達や別の工場４００への再発注等の費用が発生する可能性がある。しかし、印刷の発注とは無関係に用紙の補充を印刷受発注サーバ３００が手配する場合には、前述したように、依頼者の希望する工場４００に印刷が発注される可能性が高くなるので、追加の費用の発生を抑制することができる。
また、前述の実施の形態では、各工場４００からリアルタイムで収集されるデータや印刷の受発注の履歴等を利用して用紙の需要を予測しているが、印刷受発注とは関係ないオープンデータ（例えば天候、物流、消費動向等のビッグデータ）も人工知能に与えて用紙の需要を学習すれば、予測の精度を一段と高めることができる。

１…ネット印刷システム、１００…インターネット、２００…ユーザ端末、３００…印刷受発注サーバ、３０４Ａ…依頼者データベース、３０４Ｂ…依頼データベース、３０４Ｃ…工場データベース、３０４Ｄ…学習済みモデル、３０４Ｅ…用紙データベース、３０４Ｆ…予測需要データベース、３１１…オーダ受付部、３１２…発注先決定部、３１３…発注部、３１４…受発注関係学習部、３１５…分析データ計算部、３１６…情報提供部、３５０…用紙管理サーバ、４００…工場、５００…データ収集サーバ、５０４Ａ…生データデータベース、５０４Ｂ…クレンジング済み生データデータベース、５０４Ｃ…分析結果データベース、５１１…生データ収集部、５１２…クレンジング部、５１３…データ分析部、５１４…データアップロード部、５１５…発注情報受信部、６００…印刷装置、７００…加工装置、８００…ワークフロー管理装置、９００…在庫管理装置、１０００…センサ

Claims (6)

1. ユーザの端末から、印刷オーダを受信する手段と、
   前記ユーザについて予め登録されている又は前記印刷オーダに含まれる要求仕様を満たす工場を特定する手段と、
   特定された前記工場が、前記印刷オーダを実行するのに十分な用紙の在庫を有しているか否かを、工場毎の在庫を格納するデータ格納部を参照して判断する手段と、
   特定された前記工場が前記印刷オーダを実行するのに十分な用紙の在庫を有していない場合、特定された前記工場に対して用紙を供給する用紙供給元から当該工場への配送にかかる時間を加味して、用紙の補充に伴う納期の超過時間を予測する手段と、
   予測された前記超過時間が、前記要求仕様に予め含まれる、納期遅れの許容期間以内であるか否かを判断する手段と、
   予測された前記超過時間が前記納期遅れの許容期間以内である場合には、特定された前記工場を発注先の工場として決定し、当該工場のコンピュータに前記印刷オーダについてデータを送信する手段と、
   を有する印刷発注システム。
2. 特定された前記工場が発注先の工場として特定された場合、当該工場に対して用紙を供給する用紙供給元のコンピュータに、当該工場への用紙の補充を要求するデータを送信する手段
   をさらに有する請求項１記載の印刷発注システム。
3. 前記要求仕様が、前記ユーザが希望する１又は複数の工場の指定を含む
   請求項１又は２記載の印刷発注システム。
4. 前記ユーザについて予め登録されている又は前記印刷オーダに含まれる要求仕様に、前記ユーザが希望する１又は複数の工場の指定を含まない場合、前記印刷オーダを実行するのに十分な用紙の在庫を有していない工場を発注先の候補から除外した上で、前記要求仕様に基づき発注先の工場を決定する手段
   をさらに有する請求項１乃至３のいずれか１つ記載の印刷発注システム。
5. ユーザの端末から、印刷オーダを受信するステップと、
   前記ユーザについて予め登録されている又は前記印刷オーダに含まれる要求仕様を満たす工場を特定するステップと、
   特定された前記工場が、前記印刷オーダを実行するのに十分な用紙の在庫を有しているか否かを、工場毎の在庫を格納するデータ格納部を参照して判断するステップと、
   特定された前記工場が前記印刷オーダを実行するのに十分な用紙の在庫を有していない場合、特定された前記工場に対して用紙を供給する用紙供給元から当該工場への配送にかかる時間を加味して、用紙の補充に伴う納期の超過時間を予測するステップと、
   予測された前記超過時間が、前記要求仕様に予め含まれる、納期遅れの許容期間以内であるか否かを判断するステップと、
   予測された前記超過時間が前記納期遅れの許容期間以内である場合には、特定された前記工場を発注先の工場として決定し、当該工場のコンピュータに前記印刷オーダについてデータを送信するステップと、
   を、コンピュータに実行させるためのプログラム。
6. ユーザの端末から、印刷オーダを受信するステップと、
   前記ユーザについて予め登録されている又は前記印刷オーダに含まれる要求仕様を満たす工場を特定するステップと、
   特定された前記工場が、前記印刷オーダを実行するのに十分な用紙の在庫を有しているか否かを、工場毎の在庫を格納するデータ格納部を参照して判断するステップと、
   特定された前記工場が前記印刷オーダを実行するのに十分な用紙の在庫を有していない場合、特定された前記工場に対して用紙を供給する用紙供給元から当該工場への配送にかかる時間を加味して、用紙の補充に伴う納期の超過時間を予測するステップと、
   予測された前記超過時間が、前記要求仕様に予め含まれる、納期遅れの許容期間以内であるか否かを判断するステップと、
   予測された前記超過時間が前記納期遅れの許容期間以内である場合には、特定された前記工場を発注先の工場として決定し、当該工場のコンピュータに前記印刷オーダについてデータを送信するステップと、
   を含み、コンピュータが実行する方法。

Images