JP2005522788A - インテリジェント許可返却システム及び方法 - Google Patents

Abstract

本発明は、フィールドサービス技術者に配布されたパーツを返却する際に使用するための出荷ラベルの提供のためのシステム及び方法を開示する。保守部品注文要求を、１つまたは複数の規則と対照して処理し、印刷され、保守部品とともにパッケージの中に同封される返却出荷ラベルを作成するシステムが開示されている。フィールドサービス技術者は保守部品のステータスを特定し、それらを処理する体制が整っている施設に対する使用済みの保守部品と未使用の保守部品の両方の時宜に適った返却を保証するために適切な返却出荷ラベルを使用する。

Description

本発明はリバースロジスティクスの分野に関する。具体的には、本発明は保守部品を返却する際に使用するための出荷ラベルをフィールドサービス技術者に提供するためのシステム及び方法である。

ハイテク装置の製造における傾向は複数の外部供給業者からのモジュール部品の組み立てに向かっている。この傾向の結果、フィールドサービス技術者、つまりこれらの製品のアフターサービス保守及び修理の責任者であるそれらの個人は、一般的には診断と修理ではなく診断と交換により重点を置いている。つまり、第三者の供給業者から調達されたモジュール部品に問題が起因する場合、該部品は製造業者またはその修理スタッフのどちらかによる現場での修理に影響を受けなくてもよい可能性がある。

従って現代のフィールドサービス技術者の効率の多くは、問題発生時に手元に正しい交換パーツを有することにかかっている。技術者が修理を行うために現場に複数回出向かなければならない場合、アフターサービスにおける節約及び効率は障害を生じさせるか、失われるかのどちらかである。従って、一般的には、フィールドサービス技術者は、問題を診断するために１回目に出かけ、それを修理するために該部品を持っていくために２回目に出かけるよりむしろ、余分な保守部品を修理現場に持っていく方がより効率的である。

しかしながら、フィールドサービス技術者をスペアパーツの多様な選択を備えた修理現場に行かせることに対する欠点がある。１つの欠点は、どの保守部品が実際に修理で使用されるかに関する表示がほとんどないときに保守部品の在庫レベルを追跡調査し、管理することに固有の困難である。任意の修理の場合、技術者が現場に持っていく保守部品のいくつかまたはすべてが修理に使用されない可能性がある。これらのパーツは、次にそれらが次のサービスコールのために使用可能にされる保守部品倉庫または他の保管施設に送り返される。

例の目的のため、例示的なサービスコールが図１に描かれている。フィールドサービス技術者は、ステップ１でサービスコールを知らされ、問題について書面によるまたは口頭での説明を受ける。ステップ２で技術者は、技術者が受けた書面によるまたは口頭での説明に基づいて問題の予備的な診断を行い、ステップ３で技術者は、必要とされる可能性があるものに関する技術者の初期の印象に基づいて複数の保守部品を注文する。

保守部品は通常、集配送センタまたはフィールド備蓄場所のどちらかで倉庫に入れられる。一般的には、集配送センタよりはるかに多くのフィールド備蓄場所がある。従って、現場の技術者がただちにパーツを必要とする場合、該パーツは一般的にはフィールド備蓄場所から注文されるが、それほど時間に敏感ではない保守部品の注文は一般的には集配送センタから補充される。

ステップ４では、現場の技術者がステップ３で注文した保守部品が「集荷用待機」プロセスとして知られていることでの運搬装置集荷サイトに送られる。保守部品がフィールド備蓄場所から注文されたのか、あるいは集配送センタから注文されたのかに応じて、パーツはそれらが注文されてから数時間から数日後のどこかで運搬装置集荷サイトに到着する。ステップ５では、フィールドサービス技術者は保守部品を引き取る。過去においては、フィールドサービス技術者は通常の営業時間中にだけ保守部品を引き取ることができた。しかし、近年ではＵＰＳ（Ｕｎｉｔｅｄ Ｐａｒｃｅｌ Ｓｅｒｖｉｃｅ ｏｆ Ａｍｅｒｉｃａ、Ｉｎｃ．）などの運送会社が、サービス技術者が２４時間パーツを引き取ることができるようにする集荷用待機サービスを提供している。

「集荷用待機」プロセスでは、製造業者は多様な現場全体に広がる装置を修理するために現場の技術者を有し、これらの技術者は多くの場合備蓄場所または集配送センタから修理部品を即時に必要としている。製造業者がパーツを含むパッケージの通常のまたは夜間の配達を要求すると、技術者は昼近くまで修理パーツを受け取れないであろう。早朝配達オプションも使用可能な場合があるが、それらは多くの場合高価すぎて、製造業者は定期的に使用できない。集荷用待機プロセスでは、製造業者は、パッケージが早朝技術者による個人集荷用のジョブサイトに最も近い運送業者の整理ポイントで保持されることを要求する。運送業者の施設から荷受人に対する小型車両による最終的な配達がパッケージ輸送プロセスの高価な部分であるために、この手順はパッケージの早期受領及び低コストという二重の利点を有する。

ステップ６では、フィールドサービス技術者は該パーツを引き取り、それらを、技術者が必要とされる修理を完了する修理サイトに持っていく。この例の目的のため、フィールドサービス技術者が修理のために５個のパーツを注文し、修理を行う際に該パーツの内の３個を使用したと仮定する。さらに、この例では、交換されたパーツの内の１つが保証期間中であり、製造業者または部品パーツ製造業者に、修理のために返却される必要があると仮定する。従って、この説明図では、修理が完了した後で、フィールドサービス技術者は、いままで使用されなかった「新規」パーツと修理する必要がある「使用済み」パーツを持っている。

さらに状況を複雑にするのは、現場の技術者は日々対処する８から１０個の修理の問題点に直面することである。その結果、技術者が在庫に戻す及び／または修理のためのパーツを送り返す機会を得る（ステップ７）まで、スペアパーツ及び使用済みパーツを修理トラックまたは箱型貨物自動車の中に３週間も保管することは該当分野の技術者にとっては何も変わったことではない（ステップ７）。

ステップ８では、フィールドサービス技術者は、在庫に戻すためにスペアパーツを送り返し、修理対象の使用済みのパーツを送り返す。技術で既知であるように、現場の技術者が、毎週丸一日費やし、パーツをかき分けて調べ、どのパーツがどの修理に関連付けられているのか、及びどこにパーツを返却するのかを決定することは変わったことではない。いくつかのケースでは、未使用の保守部品は、技術者がかき分けて調べ、パーツを多様な集配送センタ及びフィールド備蓄場所に送り返す機会を得るまで２週間以上修理トラックの中に保持されることがある。

前述されたプロセスの元では、後述される複数の重要な問題点が注記された。未使用のパーツの返却の遅延は、非効率的且つ不正確な製品在庫管理を生じさせる。どのような瞬間にも、企業には、修理トラック内にある、あるいはさまざまな期間パーツを保持していた技術者から集配送センタ及びフィールド備蓄場所への移動中の数百万ドルに値する未使用の保守部品がある可能性がある。企業はどの保守部品が修理に使用されたのか、及び在庫に戻すためにどれが最終的に返却されるのかを知らないため、企業はパーツ在庫管理の問題に遭遇する。

前述されたプロセスに関連付けられた別の問題点は、料金請求書作成発行における重大な遅延である。前記説明図では、フィールドサービス技術者は修理のために５個のパーツを注文したが、修理を行う際に５個のパーツの内の３個を使用しただけである。通常、企業は、保守パーツが返却されるまで修理についてそのカスタマに請求することはできず、企業は修理でパーツのどれが使用されたのかを判断する。このようにして、技術で使用されているカスタマ料金請求書作成発行サイクルは、一般的には、企業とフィールドサービス技術者が修理でどのパーツが使用されたのか、及びどれが在庫に戻されたのかを判断している間延期される。

前記例により描かれているさらに別の問題点は使用済みパーツの処理である。いくつかのケースでは、サービス技術者は保証プロセスのパーツとして置換されたパーツを出荷し、他のケースでは、パーツの値はその修理を正当化するであろう。使用済みのパーツの問題点は多くの場合、パーツが現場の技術者からの、パーツが在庫に戻されるのか、あるいは修理のために送られるのかに関する指示なしに到着するときに集配送センタ及びフィールド備蓄場所で生じる。いくつかの倉庫では、企業は、現場の技術者から受け取られるパーツが修理を必要としているかどうかを判断するための入り組んだ試験動作を確立している。これらの多くの場合手作業の試験動作は高価なだけではなく、エラーを受けやすい。

従って、業界には、いくつかが前述された従来の技術の欠陥を克服する改善された保守部品返却システムに対する満たされていないニーズがある。

発明の概要
本発明はフィールドサービス技術者に配布されたパーツを返却する際に使用するための出荷ラベルの提供のためのシステム及び方法を開示する。保守部品注文要求を、１つまたは複数の規則と対照して処理し、印刷され、保守部品とともにパッケージの中に同封される返却出荷ラベルを作成するシステムが開示されている。フィールドサービス技術者は保守部品のステータスを特定し、それらを処理する体制が整っている施設に対する使用済みの保守部品と未使用の保守部品の両方の時宜に適った返却を保証するために適切な返却出荷ラベルを使用する。

本発明の実施形態に従って、現場の技術者にパーツを出荷するための、該パーツに関連付けられたパーツ識別子を含む注文書を受け取るステップと、該パーツ識別子でパーツデータベースを照会し、前記パーツが在庫にある倉庫を特定するステップと、１枚のアウトバウンド出荷ラベルと１枚または複数枚の返却出荷ラベルを該注文に関連付けるために、及び該アウトバウンド出荷ラベル用に及び該１枚または複数枚の返却出荷ラベル用に出荷ラベルデータを生成するために出荷ラベルデータを規則エンジンと対照して該注文を処理するステップと、倉庫で該アウトバウンド出荷ラベル及び該１枚または複数枚の返却集荷ラベルを印刷するステップと、パーツとともにパッケージの中に１枚または複数枚の返却出荷ラベルを同封するステップと、パッケージにアウトバウンド出荷ラベルを貼るステップと、現場の技術者にパッケージを出荷するステップとを含む現場の技術者に保守部品を提供する方法が説明されている。

別の関連する実施形態では、倉庫を特定するためにパーツデータベースを照会するステップは、パーツが入手可能であるかどうか、及び入手できる場合にはパーツがどこに位置しているのかを確定するためにパーツデータベースを照会することを含む。別の実施形態では、倉庫を特定するためにパーツデータベースを照会するステップが在庫にパーツがある倉庫を特定するステップと、パーツを確保するためにパーツデータベース内にフラグをセットするステップと、出荷のためにパーツを採取させるために倉庫に連絡をするステップとを含む。さらに別の実施形態では、倉庫を特定するためにパーツデータベースを照会するステップは、パーツが入手可能であるかどうかを判断するためにパーツデータベースに照会し、入手できない場合にはパーツをバックオーダすることとを含む。さらに別の開示されている実施形態では、規則エンジンに対照して注文を処理するステップは、企業Ｊａｖａビーンクライアントを介する企業Ｊａｖａビーンへの提出のための注文アレイに該注文を変換するステップと、企業Ｊａｖａビーンの中に注文アレイを受け取るステップと、規則エンジンによる処理に適したＪａｖａ注文オブジェクトを作成するステップと、注文オブジェクトを規則エンジンに渡すステップとを含む。

別の関連実施形態では、１枚または複数枚の返却出荷ラベルのために出荷ラベルデータを生成するステップが、第１の及び第２の返却出荷ラベルのためにラベルデータを生成することを含み、第１の返却出荷ラベルが返却されるパーツを使用済みとして識別し、第２の返却出荷ラベルが返却されるパーツを未使用として識別する方法が説明される。別の実施形態では、１枚または複数枚の返却出荷ラベルのために出荷ラベルデータを生成するステップが、現場の技術者が修理、在庫に戻すこと、廃物利用及び処分の少なくとも１つのために使用済みパーツを出荷できるようにする出荷ラベルのためのデータを生成することとを含む。さらに別の説明される実施形態では、アウトバウンドラベル及び１枚または複数枚の返却出荷ラベルを倉庫で印刷するステップが、出荷ラベルデータを電子形式で倉庫に配置される印刷装置に送信することと、アウトバウンドラベル及び１枚または複数枚の返却出荷ラベルを印刷装置で印刷することとを含み、出荷ラベルに印刷される情報は少なくとも部分的には出荷ラベルデータに基づいている。さらに別の実施形態では、アウトバウンドラベル及び１枚または複数枚の返却出荷ラベルを倉庫で印刷するステップは、出荷ラベルデータを電子形式で倉庫に関連付けられたコンピュータシステムに送信することと、該倉庫コンピュータシステムの手動起動時に運送業者アプリケーションに出荷ラベルデータを転送することと、アウトバウンド出荷ラベル及び１枚または複数枚の出荷ラベルのそれぞれにパッケージ追跡調査番号を割り当てることと、少なくとも部分的に出荷ラベルデータに基づいたアウトバウンド出荷ラベル及び１枚または複数枚の出荷ラベルを作成することと、倉庫でアウトバウンド出荷ラベル及び１枚または複数枚の出荷ラベルを印刷することとを含む。

また、別の開示される実施形態では、前述された方法は、アウトバウンド出荷ラベルに、及び１枚または複数枚の返却出荷ラベルのそれぞれにパッケージ追跡調査番号を割り当てるステップを含む。そして、別の関連する実施形態では、１枚または複数枚の返却出荷ラベルをパーツともにパッケージに同封するステップが、倉庫内の保管領域からパーツを採集するステップと、パーツをパッケージに入れるステップと、印刷装置から１枚または複数枚の返却出荷ラベルを検索するステップと、パッケージに１枚または複数枚の返却出荷ラベルを同封するステップとを含む。

本発明の別に実施形態に従って、ユーザから、少なくとも１つの保守部品番号を含む注文データを受信するように構成される受注アプリケーションと、注文データを受信し、保守部品番号でパーツデータベースを照会し、保守部品の可用性を突き止めるように構成される、受注アプリケーションと電子的に通信するパーツ管理アプリケーションと、注文データを受信し、１つまたは複数の規則に対照して注文データを処理するように構成される、受注システム及びパーツ管理アプリケーションの少なくとも一方と電子的に通信する規則エンジンであって、少なくとも部分的に１つまたは複数の規則に基づいて出荷ラベルデータを生成するようにさらに構成される該規則エンジンと、少なくとも部分的に出荷ラベルデータに基づく少なくとも１枚の出荷ラベルを印刷するように構成される印刷装置とを含む保守部品出荷システムが説明される。

別の関連実施形態では、パーツ管理アプリケーションは保守部品を在庫に有する倉庫を特定するようにさらに構成される。追加の実施形態では、パーツ管理アプリケーションは、保守部品を確保し、入手できない保守部品をバックオーダするようにさらに構成される。さらに別の説明される実施形態では、規則エンジンは運送業者規則、物流管理規則、及びユーザ定義規則の内の少なくとも１つに対照して注文データを処理するように構成される。別の実施形態では、規則エンジンはアウトバウンド出荷ラベル及び返却出荷ラベルのために出荷ラベルデータを生成するように構成される。

別の実施形態では、規則エンジンは第１の返却出荷ラベルと第２の返却出荷ラベルのために出荷ラベルデータを生成するように構成され、第１の返却出荷ラベルは返却されるパーツを使用済みとして特定し、第２の返却出荷ラベルは返却されるパーツを未使用として特定する。さらに別の実施形態では、規則エンジンは、現場の技術者が修理、在庫に戻すこと、廃物利用、及び処分の内の少なくとも１つのために使用済みパーツを出荷できるようにする返却出荷ラベルのために出荷ラベルデータを生成するように構成される。

さらに別の実施形態では、システムは、出荷ラベルデータを受信するように構成され、出荷ラベルデータを運送業者システムに送信し、運送業者システムから出荷ラベル画像を受信するようにさらに構成される倉庫アプリケーションと、運送業者システム上に常駐し、出荷ラベルデータを受信し、出荷ラベル画像を生成するように構成される出荷ラベル作成アプリケーションとをさらに含むために説明される。さらに別の実施形態では、出荷ラベルアプリケーションは、出荷ラベル画像を印刷装置に送信するように構成され、印刷装置によって印刷される出荷ラベルは少なくとも部分的に出荷ラベル画像に基づいている。

本発明の別の実施形態に従って、現場の技術者への保守部品出荷要求を含む保守部品要求を受信するステップと、保守部品要求に応えてアウトバウンド出荷ラベル及び返却出荷ラベルを作成するステップと、第１の保守部品追跡調査番号をアウトバウンド出荷ラベルに、第２の保守部品追跡調査番号を返却出荷ラベルに割り当てるステップと、第１の保守部品追跡番号と第２の保守部品追跡番号を含む、保守部品トランザクションデータベースに保守部品要求についての情報を記憶するステップと、運送業者を通して出荷されるパッケージについての、パッケージ出荷ステータスとパッケージに関連付けられるパッケージ追跡調査番号を含むパッケージレベル詳細情報を捕捉するステップと、パッケージ追跡調査番号が第１のまたは第２の保守部品追跡調査番号に対応するとパッケージレベル詳細情報で保守部品トランザクションデータベースを更新するステップとを含む、現場の技術者に出荷される保守部品のステータスを監視する方法が開示される。

発明の詳細な説明
本発明は、本発明の好適実施形態が図示される添付図面に関してここでさらに詳しく以下に説明される。しかしながら、本発明は多くの異なる形式で具体化され、ここに述べられる実施形態に制限されると解釈されるべきではない。むしろこれらの実施形態は、この開示が綿密且つ完全となり、当業者に本発明の範囲を十分に伝えるように示される。全体を通して類似する番号は類似する要素を指す。

前記説明及び関連付けられた図面に提示された教示の利点を有する本発明の多くの変型及び他の実施形態が、本発明が関係する当業者の頭に思い浮かぶであろう。従って、本発明は開示される特定の実施形態に制限されるべきではなく、変型及び他の実施形態は添付請求項の範囲内に含まれることが意図されることが理解されるべきである。ここでは特殊用語が利用されているが、それらは一般的且つ記述的な意味でのみ使用され、制限の目的のためには使用されない。

以下の段落では本発明の実施形態による保守部品返却システム１０を説明し、その機能はフィールドサービス技術者に配布されたパーツを返却する際に使用するための出荷ラベルを提供することである。

一般的には、保守部品は集配送センタ及び／またはフィールド備蓄場所から採集され、包装され、製品に関する修理を達成するためにパーツを使用してよい、あるいは使用しなくてよいフィールドサービス技術者に出荷される。保守部品は、現場の技術者が未使用の保守部品または、いくつかのケースでは返却される必要のある使用済みパーツを返却するために使用するであろう１枚または複数枚の出荷ラベルを伴って現場の技術者に到達する。通常、少なくとも２枚の出荷ラベルが与えられ、一方は新しいまたは未使用のパーツの返却用であり、他方は使用済みパーツの返却用である。保守部品のための返却場所は多岐に渡る注文またはパーツ属性に基づいて変わる可能性がある。使用済みパーツは返却されてよい、あるいはまったく返却されなくてよい。返却される使用済みのパーツは、好ましくはパーツを改造する、廃物利用する、及び／または安全に処分するために備えられる場所に送られる。未使用のパーツは、その出荷元の集配送施設またはフィールド備蓄場所、そのパーツの不足を経験している倉庫、あるいは後の再配布のための中心的な場所に返却される。

図２は、保守部品返却システム１０のある実施形態の構成要素の高水準ブロック図である。この実施形態では、製品の製造業者１２が製品を補修するために一人または複数人のフィールドサービス技術者１４を利用する。製造業者１２が保守要求を受信すると、製造業者１２は問題の説明とともにフィールドサービス技術者に連絡を取る。フィールドサービス技術者１４は問題の初期診断を行い、製造業者１２に、修理を達成するために必要とされる可能性のある保守部品リストを送る。

保守部品リストを受け取ると、製造業者１２はフィールドサービス技術員１４に保守部品を出荷させるために受注システム１６を使用する。該受注システム１６は、製造業者コンピュータネットワークの１つの構成要素であってよく、その場合製造業者１２は保守部品情報を注文システム１６に入力する。代わりに、受注システム１６は遠隔場所にあり、複数の製造業者にサービスを提供してよい。この代替実施形態では、製造業者１２は、注文システム１６に要求を入力するカスタマサービス代表に対する電子データ交換（ＥＤＩ）、ｅメール、ファクシミリまたは電話呼を介してを含む技術で周知である複数の手段のどれかにより受注システム１６に保守部品リストを送信する。破線を含む図２に図示されるさらに別の実施形態では、フィールドサービス技術者１４は保守部品リストを受注システム１６に直接的に通信する。

いったん保守部品リストが受注システム１６に入力されると、パーツリストは保守部品管理システム１８に送信される。該保守部品管理システム１８は保守部品データベース２０を照会し、要求された保守部品が入手可能であるかどうか、及び入手できる場合には、要求されたパーツがどこに位置するのかを突き止める。保守部品管理システム１８が要求されたパーツが入手可能であることに気付くと、該パーツを取っておくために保守部品データベース２０にフラグがセットされる。要求された保守部品の可用性及び場所についての情報は受注システム１６を介して製造業者１２及び／またはフィールドサービス技術者に向けられたものである。

ユーザが保守部品の可用性及び場所に満足すると、注文が受注システム１６に格納され、保守部品はそれらの備蓄場所から引き出され、出荷のために準備される。該注文は保守部品管理システム１８に送信され、保守部品データベース２０が、要求された保守部品がフィールドサービス技術員１４に出荷中であることを反映するために更新される。

代替実施形態では、注文プロセスは、注文が入力される前にパーツ可用性が確認される２ステッププロセスではない。代わりに、保守部品リストが入力されると、注文が作成され、保守部品管理システム１８に送信される。注文で参照されるパーツは、次に保守部品データベース２０に照合され、注文のために取っておかれる。パーツが入手できない場合、パーツはバックオーダされるか、あるいはパーツを供給業者からフィールドサービス技術者１４に直送させるために供給業者システムが検索される。

いったんサービス注文が発注されると、保守部品管理システム１８は、要求された保守部品を供給する集配送センタ及び／またはフィールド備蓄施設の倉庫在庫システム２２に連絡する。単一の保守部品注文に複数の集配送センタ及びフィールド備蓄場所が関与してよく、該場所のそれぞれが異なる倉庫在庫品システム２２を有することがある。本発明のある実施形態では、保守部品管理システム１８から倉庫在庫品システム２２に送信される保守部品注文は電子的に送信され、あらゆる倉庫システム２２で同じフォーマットが使用される。代替実施形態では、さまざまな倉庫システム２２が保守部品注文のさまざまなフォーマットを必要とし、サービス管理パーツシステム１８が保守部品注文をさまざまなフォーマットで提供するように構成される。

保守部品管理システム１８は、次に規則エンジン２４に対照して保守部品注文を処理する。規則エンジン２４に対照して注文を処理する動作は以下にさらに詳細に説明されている。一般的には、規則は、保守部品出荷ラベルが要求された保守部品のそれぞれに作成されるかどうか、及びどの保守部品出荷ラベルが要求された保守部品のそれぞれに作成されるのかを決定する。さらに、出荷ラベル上のフィールドのいくつかはユーザ定義可能であり、規則はこれらのフィールドに入力されるデータを決定する。

好適実施形態では、規則処理は、保守部品が採集されると発生する。出荷ラベル情報は規則プロセスから出力され、出荷ラベルテーブルに記憶される。一般的には、出荷ラベル情報は保守部品とともに包装され、フィールドサービス技術者１４によって保守部品を倉庫に送り返すために使用される出荷ラベルのための保守部品返却出荷ラベル情報を含む。さらに、フィールドサービス技術者１４にパーツを出荷するために使用されるアウトバウンド出荷ラベル用の情報が出荷ラベルテーブルに含むことができる。

規則エンジン２４に対する更新は開発ワークステーションを介してまたは保守アプリケーションを介して発生する。開発者は規則作成ワークステーションを使用し、エンジン２４内の規則を追加または修正する。修正は作成ワークステーションを通して行われるので、それらはただちに規則エンジン２４のマスタまたは製造バージョンに記憶される。対照的に、非開発者により行われる規則エンジン２４に対する追加、削除または修正は、それらが生産に移される前に最初に規則エンジン２４の品質管理または試験バージョンに記憶される。開発者が開発者ワークステーションを使用して規則の変更を達成するのに反して、非開発者は、好適実施形態では開発者の対応物よりさらにユーザフレンドリなグラフィックインタフェースを含む規則保守アプリケーションを使用する。

規則処理が完了し、保守部品が採取され、フィールドサービス技術者１４に対する出荷のために包装されると、倉庫従業員は、パーツが出荷のための準備が完了したことを示すことにより次のステップを開始する。好適実施形態では、従業員は以下の出荷プロセスを開始するために倉庫アプリケーションで出荷機能を起動する。

出荷機能が起動されると、出荷ラベル情報が、パッケージ追跡調査番号が各ラベルに割り当てられるパッケージ追跡調査システム２６に送信される。パッケージ追跡調査番号は技術で周知であり、トランザクションの関係者がピックアップから配達まで運送業者システムで運送業者システムで出荷を追跡調査できるようにする一意の識別子を備える。好適実施形態では、一意のパッケージ追跡調査番号がそれぞれの出荷ラベルに割り当てられ、パッケージ追跡調査データベースは相応して更新される。

パッケージ追跡調査番号が割り当てられると、保守部品管理システム１８は、要求された出荷ラベルを作成するラベル作成アプリケーション２８に出荷ラベルごとの出荷情報を渡す。次に出荷ラベルは、それらが印刷され、フィールドサービス技術者１４に出荷される保守部品が入ったパッケージに入れられる適切な集配送センタ及び／またはフィールド備蓄場所に送信される。ある実施形態では、集配送センタ及び／またはフィールド備蓄場所に送信される出荷ラベルはフィールドサービス技術者に保守部品パッケージ（複数の場合がある）を出荷するために必要とされる出荷ラベル（複数の場合がある）を含む。さらに、使用済み保守部品及び未使用の保守部品を返却するためにフィールドサービス技術者１４が使用する出荷ラベルが送信され、これらの返却出荷ラベルは保守部品が入ったパッケージ内に入れられる。

好適実施形態では、保守部品管理システム１８は、出荷されている保守部品についての詳細な情報を生成し、この情報をパッケージ運送業者にアップロードする。この情報は、例えば、パッケージの発送住所と宛て先住所、パッケージのサイズと重量及び／または出荷のサービスレベルを含んでよい。技術の普通の熟練者は、パッケージの出荷についての追加情報がプロセスのこのステップで捕捉され、アップロードされることを容易に認識するであろう。ある実施形態では、パッケージ運送業者は保守部品返却システム１０を操作し、多様な集配送センタ及びフィールド備蓄場所から保守部品を集荷し、パーツをフィールドサービス技術者に届ける責任を負っている。代替実施形態では、保守部品返却システム１０が複数の運送業者にサービスを提供し、保守部品注文が複数のパッケージ運送業者の１つを指定してよい。さらに他の実施形態では、さまざまなパッケージ運送業者が、単一の保守部品注文の中で異なる保守部品を配達するために使用されてよい。しかしながら、図解のため、以下の段落では保守部品パッケージ出荷のために単一のパッケージ運送業者が使用される保守部品返却システム１０が説明されている。

好適実施形態では、パッケージ運送業者は保守部品出荷詳細を受け取り、フィールドサービス技術者１４によって要求される保守部品を集荷するために、運送業者の運転者を出荷詳細に指定される多様な集配送センタとフィールド備蓄場所に送る。この実施形態では、保守部品が入ったパッケージには、前述したように作成された１枚または複数枚の返却出荷ラベルも含まれる。

次のステップでは、パッケージ運送業者がフィールドサービス技術者１４に保守部品を含むパッケージを配達する。好適実施形態では、フィールドサービス技術者１４によって要求される保守部品が入ったパッケージは、複数の場所から送られる。従って、パッケージは局所的な運送業者施設に送られ、フィールドサービス技術者がそれらを集荷するまでそこに保持される。好適実施形態では、フィールドサービス技術者１４に送られる保守部品パッケージは技術で既知であるような集荷用待機サービスを使用して送信される。このサービスを使用すると、保守部品が入ったパッケージが宛て先の運送業者施設に到着すると、それらは運送業者システムを通してさらに処理される代わりに、フィールドサービス技術者１４のために取りのけられ、保持辞される。技術で既知であるように、このサービスの利点とは、フィールドサービス技術者１４が保守部品が入ったパッケージに早期にアクセスし、ただちにサービスコールに進むことができるという点である。

図解のため、フィールドサービス技術者１４が任意のサービスコールのために５個の保守部品を注文し、受け取ると仮定する。この例では、技術者１４は修理を達成するために５個の部品の内の３個を使用し、加えて修理された製品から１個の使用済みパーツを入手する。技術者１４は保守部品が入ったパッケージを開けると、保守部品及び各保守部品とともに梱包された１枚または複数枚の返却出荷ラベルを回収する。

この例では、現場の技術者１４に送られた５個の保守部品の内の３個は、製品を修理するために使用され、返却されない。２個の未使用の保守部品及び１個の使用済みのパーツが返却される。好適実施形態では、２枚の返却出荷ラベルが２個の未使用の保守パーツのそれぞれとともに含まれている。該２枚の返却出荷ラベルの第１は、保守部品が使用されなかったことを示し、集配送センタ、フィールド備蓄場所または保守部品を受け取り、在庫に戻す体制が整っている他の場所の宛て先住所を有している。第２の返却出荷ラベルは、保守部品が使用済みであること、及び／または欠陥があることを示している。第２の返却出荷ラベルの宛て先住所は、通常、使用済みのパーツを修理調整するか、廃物利用するか、あるいは処分する体制が整っている施設となるであろう。

修理で使用されなかった該２個の保守部品に関して、フィールドサービス技術者１４は保守部品を荷造りし直し、パーツを未使用として識別する返却出荷ラベルを貼り付ける。代わりに、修理の間にサービス技術者が、保守部品の１個または両方とも欠陥があることを発見した場合には、技術者１４は欠陥のあるパーツが在庫に戻されるのを防ぐために使用済みとしてパーツを識別する返却出荷ラベルを貼り付けるであろう。さらに別の実施形態では、技術者１４は、修理では使用されていないが、それにも関わらず欠陥があるとしてパーツを識別する第３の返却出荷ラベルを使用できる。第３の返却出荷ラベルの宛て先住所は使用済みのパーツの宛て先と同じ上げ先である場合がある、あるいは代わりに欠陥品として識別される保守部品は欠陥パーツを供給したエンティティに送り返される。

フィールドサービス技術者１４は、修理中に入手される使用済みのパーツを返却するためにも返却出荷ラベルを使用する。使用済みのパーツを、技術者１４に出荷された保守部品の１個で交換する場合、パーツを使用済みとして識別する交換保守部品とともに同封された返却出荷ラベルが使用済みのパーツが入ったパッケージに貼り付けられる。代替実施形態では、追加の返却出荷ラベルが保証期間中のパーツについて技術者１４に提供されてよい。このようにして、代替実施形態では、サービス技術者１４は、使用済みのパーツが保証期間中であることを突き止め、製品を保証返却として識別する返却出荷ラベルが使用済みのパーツが入ったパッケージに貼り付けられる。

いったんフィールドサービス技術者１４が返却される保守部品を荷造りしなおし、適切なラベルを貼り付けると、パッケージはパッケージ運送業者に配達される。好適実施形態では、返却保守部品出荷のために使用されるパッケージ運送業者は、技術者１４に保守部品を出荷するために使用される同じ運送業者である。しかしながら、代替実施形態では、フィールドサービス技術者１４は返却出荷のために複数のパッケージ運送業者から選ぶことができる。しかしながら、パッケージ運送業者の選択肢が使用できる場合、さまざまなパッケージ運送業者が異なる出荷ラベルの書式を使用するために選択は多様な返却出荷ラベルが作成される前に下されなければならない。

保守部品が入ったパッケージ上の返却出荷ラベルは、パッケージ運送業者が返却パッケージを受け入れるときに走査される。返却出荷情報は、次にパッケージ運送業者の中央保管施設に送信される。好適実施形態では、保守部品パッケージのための返却出荷ラベルはパッケージが保守部品返却システム１０に関連付けられていることを示す。従って、保守部品返却パッケージが走査されるたびに、返却出荷情報は保守部品管理システム１８に送信される。

保守部品管理システム１８は、返却保守部品パッケージのための出荷情報を受信し、該情報を製造業者１２に転送する。好適実施形態では、出荷情報のバッチが１日の間の所定された回数、製造業者１２に送信される。しかしながら、技術の普通の熟練者は、出荷情報が、製造業者のニーズに応じて、あるいは製造業者１２の要求で多くの異なる方法で送信されてよいことを容易に認識するであろう。複数の製造業者１２が保守パーツ返却システム１０に関与できるため、保守部品管理システム１８は、任意の製造業者と関連付けられた出荷情報だけを送信する。

好適実施形態では、パッケージ運送業者の返却出荷ラベルの走査により、製造業者１２がパッケージ内に入っている保守部品、及びそのパーツのステータスを識別できるパッケージについての十分な情報が捕捉される。従って、パッケージ運送業者によって製造業者１２に提供される返却出荷情報はインバウンドである保守部品、及び各パーツのステータスと宛て先を識別する。このパッケージ出荷システムの中の可視性が高められたことで、製造業者１２はさらに高い精度をもってその保守部品在庫を予想するようになる。好適実施形態では、パッケージ運送業者は、そのシステムで輸送中であるあらゆるパッケージを走査し、パッケージ追跡調査番号を、保守部品出荷ラベル及び関連付けられるアウトバウンド出荷ラベルに割り当てられたパッケージ追跡調査番号に比較することにより、保守部品が入ったそれらのパッケージを識別する。保守パーツ追跡調査番号は、関連付けられたサービスオーダについての他の情報とともに、例えば、保守部品トランザクションデータベースに記憶されてよい。

このより高い可視性の別の利点は、修理についての請求書作成発行の遅延が排除されるという点である。技術で既知のプロセスでは、手数料は多くの場合、製造業者１２が使用済みのパーツと未使用のパーツを受け取り、フィールドサービス技術者１４によって最初に注文されたパーツのどれが修理で使用されたのかを突き止めるまで数週間延期される。本発明は、製造業者１２にその集配送センタ及び／またはフィールド備蓄場所に運送中である保守部品を通知することによりこれらの遅延を排除する。

このプロセスのさらに別の利点は、倉庫とフィールドサービス技術者１４の間での保守部品の移動について履歴データが蓄積される点である。技術の普通の熟練者にとって容易に明らかになるように、多岐に渡るレポートが、製造業者１２の貴重なツールを提供するこの履歴データから作成できる。好適実施形態では、保守部品管理システム１８は製造業者及び他のユーザに保守部品の移動についてのカスタマイズ可能なレポートを提供するレポート作成機能を含む。

ある実施形態では、システム１０のユーザは特殊なレポートを使用できる。代替実施形態では、ユーザの内の数人またはすべてが、各ユーザと関連付けられた履歴データを含む保守部品トランザクションデータベース３０にアクセスできる。トランザクションデータベース３０に対するユーザアクセスにより、ユーザは自らの照会を定式化して、カスタムレポートを作成できる。ユーザが使用できるレポートのいくつかは図３Ａから図３Ｃに描かれており、古い（aged）レポート、返却品レポート、及びターンアラウンドレポートを含む。技術の普通の熟練者は、トランザクションデータベース３０にアクセスできるユーザに追加の報告機能が提供されるのを容易に認識するであろう。

以下の段落では、本発明の実施形態のシステム構成についての詳細をさらに説明する。

図４は、本発明の別の実施形態による保守部品返却システム１０の分散アプリケーションアーキテクチャを描いている。この図では、アプリケーションサーバ５０は単一システムで表されている。しかしながら、技術の普通の熟練者は、このサーバがスケーラビリティ及び冗長性のために構成部品が分散されるサーバの集合体としてインスタンス化されてよいことを容易に認識するであろう。好適実施形態では、普通の技術の熟練者は、本発明が技術で既知の他のデータベースシステムで等しく有利であることを認識するであろうが、アプリケーションサーバ５０はオラクルのリレーショナルデータベース管理システム（ＲＤＢＭＳ）をサポートする。

運送業者出荷システム５５はネットワーク６０を介してアプリケーションサーバ５０と通信する。好適実施形態では、ネットワーク６０はイーサネットネットワークである。ただし、技術で既知の他のネットワークも使用できる。運送業者出荷システム５５はパッケージ追跡調査番号及びシステムのための関連付けられた出荷データを生成し、荷送人一日の終わりデータを関連付けられた荷送人ホストシステムにアップロードする責任を負う。好適実施形態では、運送業者出荷システム５５との通信は技術で既知であるようなＭＱＳｅｒｉｅｓ上で実行しているメッセージ待ち行列シリーズインタフェース（ＭＱＳＩ）を介して発生する。

倉庫管理サーバ６５はアプリケーションと運送業者出荷システムの両方とネットワーク６０を介して通信する。再び、単一のサーバとして表現されている一方で、倉庫管理サーバ６５は物理的には、スケーラビリティと冗長性のために構成要素が分散されたサーバの集合体としてインスタンス化されてよい。好適実施形態では、倉庫管理サーバ６５はＲＦ拡張子をオラクル統合業務システム（ＥＲＰ）に提供し、倉庫機能性を与える。運用中、倉庫管理サーバ６５はアプリケーションサーバ５０から保守部品注文データを受信し、ＭＱＳＩを介して運送業者出荷システム５５と出荷データを交換する。

ＡＲＳサーバ７０もネットワーク６０上で通信し、あるとすれば、どの出荷ラベルがシステム１０によって作成されるのかを判断する規則エンジン２４のホストして働く。好適実施形態では、ＡＲＳサーバ７０は企業Ｊａｖａビーン（ＥＪＢ）を介して規則エンジン２４を配備する。企業ビーンは該ビーンに渡される保守部品注文データに対する処理に規則を与える。

開発者ワークステーション７５及び規則維持ワークステーション８０は、開発者及び他のユーザが規則を追加、修正、及び／または削除することができるようにするインタフェースである。好適実施形態では、規則維持ワークステーション８０は、おもに技術に詳しくないユーザによって使用され、従ってこれらのワークステーションが規則に加える修正にさらに大きな制限が課される。例えば、好適実施形態では、それにより規則が実行される基準は、規則維持ワークステーション８０を介して変更できるが、規則の根本的な構造は変更できない。

好適実施形態では、開発者ワークステーション７５及び規則維持ワークステーション８０はシステムネットワーク６０及び他のシステム構成要素と、規則開発ネットワーク８５を介して通信する。好適実施形態では、規則開発ネットワーク８５はイーサネットネットワークである。しかし、技術で既知の他の種類のネットワークが本発明とともに使用できることは容易に明らかであろう。

パックアウト（packout）ステーション９０及びラベルプリンタ９５は、倉庫ネットワーク１００を介してシステムネットワーク６０に接続される。好適実施形態では、倉庫ネットワークはイーサネットネットワークであるが、再び技術で既知の他のネットワークが同じ機能性を提供するであろう。図４に表されているパックアウトステーション９０は倉庫システムに集配送センタとフィールド備蓄場所による用途を与える。好適実施形態では、これらのシステムは、アプリケーションサーバ５０及び倉庫管理サーバ６５を含む他のシステムサーバ６５に対するブラウザベースの接続性を備えたプレゼンテーション専用層を表す。ラベルプリンタ９５は、出荷ラベルが印刷されるプリンタである。好適実施形態では、Ｅｌｔｒｏｎプリンタが使用され、アウトバウンドパーツと保守部品の返却出荷ラベルの両方ともをサポートするための印刷機能性も提供する。ジェットフォームサーバ１０５（図示されていない）も、出荷ラベルの印刷を可能にする印刷待ち行列を管理するために存在する。好適実施形態では、出荷ラベル削除ファイルがジェットフォームサーバ１０５によって認識され、データが記憶されるラベルをレンダリングするラベルプリンタ９５について解釈される。

以下の段落では、本発明のある実施形態による保守部品返却システムの動作を説明する。説明は、さらに細かい詳細が続く段落及び関連する図で示されるドリルダウン形式で提示される。

図５は、保守部品返却システム１０の最高レベルのプロセスフローを描いている。高いレベルでは、システムの機能は、ユーザから保守部品注文を受け取り、注文に関連付けられた１枚または複数枚のアウトバウンド及び／または保守部品返却出荷ラベルを作成することである。

図６は、プロセスに対する第１のドリルダウンを描いている。該処理寿命は注文自体である。描かれているプロセスは保守部品注文の入力で開始する。通常、フィールドサービス技術者１４は修理の問題を診断し、技術者が問題と関連付けられている可能性があると考える保守部品を注文する。注文データはフィールドサービス技術者１４、製造業者１２、または注文入力システム１６のユーザとして働くカスタマサービス代表者のいずれかにより入力されてよい。注文データ入力はウェブ、ＥＤＩまたは手動入力を介する。

入力時、注文データはオラクルのインスタンスに複製される。再び、オラクルは周知のデータベース及びアプリケーション開発ソフトウェアベンダであるため、オラクルがここでは図解の目的で表される。本発明は他のデータベースアプリケーションとも等しく有利である。保守部品が入手可能であることが確認されると、採取のために注文がリリースされる。採取リリース時、処理は分岐し、保守部品が物理的に１つまたは複数の倉庫場所で採取されるにつれて保守部品注文が電子的に処理される。処理は、保守部品が包装され、出荷ラベルが印刷されるパックアウトステーションで再び集中する。好適実施形態では、アウトバウンド及び保守部品の返却出荷ラベルが印刷される。該返却出荷ラベルはパーツを返却するために使用するために保守部品とともにパッケージ内に入れられ、アウトバウンド出荷ラベルはフィールドサービス技術者１４への出荷のためにパッケージに貼り付けられる。描かれているように、オラクルはプロセスの多くに入力を与え、プロセスから入力を受け取る。

図７は、保守部品返却システム１０プロセスがオラクルに記憶されたプロシジャにより呼び出されることを描いている。該オラクルプロシジャは、オラクル内に常駐する保守部品に記憶されるプロシジャを呼び出す。好適実施形態では、保守部品に記憶されるプロシジャは、その入力として保守部品注文データから注文番号を受け取る。

図８は、渡された注文番号をパラメータとして使用してオラクルから注文データが検索される、保守部品に記憶されるプロシジャの中から始まるプロセスを描いている。注文データは、規則が適用されると、後で使用するために始点ゾーンと目的地ゾーンを識別するために前処理される。次にデータが実装され、規則処理エンジンとしての役割を果たすＥＪＢをインスタンス化するために使用される。好適実施形態では、このＥＪＢのインスタンス化はｊａｖａ記憶手順（ＪＳＰ）を介して行われ、ビーンは、それを呼び出すオラクルインスタンスに遠隔である場合もあれは、遠隔ではない場合もある規則サーバ上で呼び出される。

いったんインスタンス化されると、ビーンは受け渡された保守部品注文データに指定されるデータを適用し、規則処理を完了するために必要な場合には追加のオラクルデータが検索できる。規則に対照して注文データを処理した後、ＥＪＢは出荷ラベルデータを、後処理が発生する呼び出し側のサービスパーツ記憶プロシジャに戻し、オラクルは出荷ラベルデータで更新される。

図９は、本発明の実施形態による検索および前処理動作を描く。前述されたように、保守部品注文データは、注文番号を使用してオラクルから検索され、オラクル採取リリース記憶プロシジャから渡される。好適実施形態では、検索されたデータは保守部品の属性だけではなく、ヘッダデータと行データの両方も含む。その注文が処理中であるユーザがゾーンのアイデアを活用する場合には、出荷先住所と出荷元住所に関連付けられるゾーンが決定される。次にこの更新された情報は、ＥＪＢクライアントを介してＥＪＢに提出するためにアレイ内で作成される。

図１０は、ＥＪＢクライアントの呼び出しを描いている。好適実施形態では、ＥＪＢクライアントはオラクルＲＤＢＭＳシステムで実現されるＪａｖａクライアントである。ＥＪＢクライアントは保守部品注文データのアレイを受け取り、規則エンジン２４によろう処理に適したＪａｖａ注文オブジェクトを作成し、そのオブジェクトを規則エンジン２４に渡す。規則を注文データに適用した後、ＥＪＢクライアントはデータを最初に渡すために使用されるアレイを介して呼び出し側オラクル記憶プロシジャにもう一度注文データを戻す。この実施形態では、オラクルプロシジャに戻されるアレイの中に、規則処理の結果である出荷ラベルデータを含む新しいアレイがある。

図１１は、本発明の実施形態による規則の適用を描いている。規則の適用は２つの点で階層的であり、順序は最初にヘッダレベルで、及び必要な場合行レベルで調べられる。初期の規則は、保守部品の処理が必要とされているのかどうかを判断するために注文ヘッダデータを見る。処理が必要とされていない場合、注文は処理済みであるが、保守部品出荷ラベルを必要としないとしてフラグが立てられる。

注文データが、保守部品の処理が必要とされることを示す場合には、各注文行が処理される。運送業者規則がそれぞれに適用される。運送業者規則は、運送業者がそのシステムの中で出荷されたパッケージに対して適用する運送業者に特殊な規則の集合である。運送業者規則は、例えば、特定の場所へまたは特定の場所からのパッケージ出荷のために陸上輸送が使用されるという要件を含む場合がある。保守部品返却システムとの関連で、運送業者が、保守部品のトランザクションが特定の領域でのみ、あるいは特定の条件でのみ使用可能であることを必要とする場合がある。

運送業者規則処理が、保守部品出荷ラベルがこの品目名に作成される必要がないことを示す場合、局所的な注文データは更新され、次の注文品目名が処理される。運送業者規則が保守部品返却出荷ラベルの作成を排除しないと仮定すると、保守部品ロジスティクス規則が適用される。保守部品ロジスティクス規則は運送業者ごとに変わる可能性がある。好適実施形態では、保守部品ロジスティクス規則は、サービスオーダ要求を作成したカスタマが有効な料金請求書作成発行アカウント番号を有していることを確認するためのチェックを含む。技術の普通の熟練者にとって容易に明白となるように、ユーザ及び／または保守部品注文情報に基づいてこのステップで追加のチェックが実行されてよい。

好適実施形態では、運送業者規則と保守部品ロジスティクス規則の一方または両方が、保守部品出荷ラベルが任意の品目名に作成されてはならないことを示す場合がある。運送業者規則も、保守部品ロジスティクス規則も保守部品出荷ラベルの作成を排除しないと仮定すると、注文項目データが更新され、ユーザ特殊規則が注文行に適用される。

各注文行は前記ステップに従って処理される。すべての注文行が処理されると、ＥＪＢは、出荷ラベルデータをオラクルに格納する際に使用するために更新済みの注文データを戻す。このデータは、それが実装され、保守部品記憶プロシジャに戻されるＥＪＢクライアントに戻される。

図１２は、オラクルデータベースを更新することに備えて注文オブジェクト・データを受信し、処理するプロセスを描いている。好適実施形態では、後処理出荷データが規則エンジン２４により格納された住所コードと受領コードを分解するニーズを識別する。これらのコードは完全な住所情報をオラクルロケーションで探し、どのデータが保守部品出荷ラベルのユーザ定義領域を埋めるのかを決定するためのキーとして使用される。アドレス及び受領の情報は、保守部品出荷ラベルテーブルを埋めるために使用される。

図１３は、本発明のある実施形態によってオラクルを更新するプロセスを描く。好適実施形態では、オラクルデータベースは、住所データ、サービスレベルフィールドと基準フィールドなどの運送業者データ、及びユーザに特殊な基準値を含む３種類のデータで更新される。また、好適実施形態では、これらのデータ要素のすべてが保守部品ラベルデータテーブルに記憶される。

図１４は、採取及び出荷注文プロセスのステップを描く。このプロセスは、保守部品が保管される集配送センタとフィールド備蓄で発生する。倉庫で注文が受け取られると、参照された保守部品が貯蔵庫から採取され、出荷のために包装される。前述された並行処理の一部として、アウトバウンドと保守部品の返却出荷ラベルが、倉庫内のパックアウトステーションで作成され、印刷される。保守部品返却出荷ラベルは保守部品とともにパッケージの中に入れられる。アウトバウンド出荷ラベルはパッケージに貼り付けられ、パッケージが配置される。

出荷ラベルを印刷するプロセスは図１５と図１６に描かれている。プロセスは集配送センタまたはフィールド備蓄場所のパックアウトステーションで発生する。好適実施形態では、倉庫従業員が、ＸＭＬ印刷要求文書を作成する倉庫管理サーバインタフェース上の「出荷」ボタン（または類似した名前）を起動することによりプロセスを開始する。本文書はＭＱシリーズを介して配達され、ＭＱＳＩによりストリームの中ほどで処理される。次にＸＭＬデータは運送業者出荷システム５５に送信され、結果として生じる出荷データは倉庫管理サーバ６５に戻され、オラクルデータベースを更新する。倉庫管理サーバ６５に送信される更新も、ＸＭＬ文書としてＭＱシリーズを介する。好適実施形態では、運送業者出荷システム５５から返される出荷データはプリンタ削除ファイルを作成するために使用される。削除ファイルは、その後、出荷ラベルが関連付けられたプリンタで印刷されるように適切なディレクトリに置かれる。

好適実施形態では、ＭＱＳＩによって受け取られる出荷要求文書は、アウトバウンドと保守部品両方の返却出荷ラベルを印刷するために必要なデータを含む。ＭＱＳＩはデータを解析し、出荷ラベルごとにＸＭＬ文書を作成する。これらの文書は図１６でＸＭＬ追跡調査要求文書として識別される。各ＸＭＬ追跡調査要求文書は、次に、パッケージ追跡調査番号と転送コードを含む出荷データを生成する運送業者出荷システム５５に送信される。運送業者出荷システム５５は、次に、ＭＱＳＩに戻されるＸＭＬ出荷要求文書として出荷データをフォーマットする。ＭＳＱＩはＸＭＬ出荷要求文書をバッファに入れ、プリンタ削除ファイルを作成するためにそれを使用する。さらに、ＭＱＳＩは、倉庫管理サーバ６５を新しい出荷詳細で更新するために使用されるＸＭＬ印刷更新文書を書式設定する。出荷ラベルデータのすべてが処理されると、プリンタ削除ファイルを作成するために使用されるデータがメモリに記憶される。

図１７は、プリンタ削除ファイルを作成するために必要とされるプロセスを描く。好適実施形態では、プリンタ削除ファイルの作成はメモリ内でバッファに入れられる出荷ラベルデータを反復することを必要とする。出荷ラベルデータに遭遇するたびに、それは適切なフォーマットでプリンタ削除ファイルに書き込まれる。この実施形態では、アウトバウンドラベルデータは、このデータもプリンタ削除ファイルに書き込まれる最後まで除外される。アウトバウンドラベルは、アウトバウンド出荷ラベルが、任意のパッケージの最後のラベルが印刷を完了した旨の倉庫人員に対するインジケータとしての役割を果たすように最後の通過まで保存される。

図１８及び図１９は、本発明の実施形態による保守部品返却出荷ラベル１１０を描いている。各出荷ラベル１１０は、出荷元住所１１２、出荷先住所１１４、Ｍａｘｉｃｏｄｅ（登録商標）１１６、郵便局コード１１８、郵便局バーコード１２０、パッケージ追跡調査番号１２２、運送業者バーコード１２４、パッケージ重量１２６及びサービスレベル識別子１２８を含む。出荷ラベルは、保守部品返却システム１０の一部としてラベルを識別する特殊フィールドも含む。これらのフィールドはパーツ番号１３０、カスタマ参照フィールド１３２、保守部品条件識別子１３４、注文番号１３６、１つまたは複数のユーザカスタマイズ可能な領域１３８を含む。

好適実施形態では、フィールドサービス技術者１４が出荷するパーツ番号１３０が保守部品を識別し、保守部品条件識別子１３４が、パーツが使用済みであるのか、未使用であるのかを示す。使用済みのパーツの場合には、出荷先住所１１４は製造業者、パーツ供給業者または使用済みのパーツを受け取り、取り扱う体制が整っている他のエンティティの住所であってよい。ある実施形態では、使用済みのパーツの取り扱いは、少なくとも部分的にはパーツ番号に基づく。例えば、第１の使用済みのパーツは修理される施設に出荷されるが、第２の使用済みのパーツは廃物利用領域に出荷され、第３の使用済みのパーツは処分場所に出荷される。ある実施形態では、条件識別子領域１３４で未使用と識別される保守部品は、それらの発送もとの集配送センタまたはフィールド備蓄場所に、あるいは代わりにそのパーツの在庫が少ない倉庫場所に戻される。

保守部品返却出荷ラベル１１０のカスタム基準フィールドは、注文番号、パーツ番号、アウトバウンドパッケージ追跡調査番号、または配置番号の１つまたはすべてを含むことがある。カスタマ参照基準フィールド１３２はユーザカスタマイズ可能であるため、フィールドを埋めるために使用される情報はユーザごとに異なり、製造業者１２または他のカスタマが出荷ラベルに記載することを要求する追加の情報を含んでよい。

さらに、複数のユーザカスタマイズ可能フィールド１３８が出荷ラベル１１０の一番下に含まれる。これらのフィールド１３８は、ユーザがラベルに記載することを希望する追加情報を含んでよい。例えば、保守部品は特に脆弱である場合があり、これらのフィールドは、出荷ラベルが該パーツについて作成されるときにはかならず特殊梱包指示を含んでよい。代わりに、ユーザカスタマイズ可能フィールド１３８は、フィールドサービス技術者１４に、保守部品とともに含まれる多様な出荷ラベルをいつ、どのようにして使用するのかを指示してよい。技術の普通の熟練者は、個々のユーザがこれらのカスタマイズ可能なフィールド１３８に対する特殊化されたニーズを有してよく、これらのニーズが本発明により包含されることを意図されることを容易に認識するであろう。

好適実施形態では、修理のために保守部品を受け取るフィールドサービス技術者は、図１８と図１９に描かれる出荷ラベル１１０を受け取る。出荷ラベル１１０は同じ保守部品を返却するための代替出荷ラベルであるため、ラベルフィールドの多くは、制限なく、パーツ番号、カスタマ参照番号、出荷元住所、パッケージ重量、サービスレベル及びＲＣＶ参照番号を含む同じ情報を使用する。好適実施形態では、ラベル１１０は、運送業者が出荷ラベルのどれが返却に使用されるのかを特定できるようにするさまざまなパッケージ追跡番号を有する。好適実施形態では、パッケージ追跡調査番号は、パッケージが受け入れられ、パッケージ追跡調査番号がパッケージの出荷ラベルと内容物を特定するために１つまたは複数の保守部品追跡調査番号と比較されるときに運送業者により走査される。この情報は、このようにして運送業者カスタマが利用できるようになり、彼らに輸送中の保守部品についての追加された可視性を提供し、このようにしてパーツ在庫の精度及び効率、ならびに時宜を得た料金請求書作成発行の開始を実現する。

図１８の出荷ラベル１１０は、修理に使用されない保守部品を返却するために使用される。この例図では、ラベルの条件識別子１３４及び出荷先住所１１４がパーツを未使用と識別する。さらに、ラベル１１０のユーザカスタマイズ可能領域１３８がフィールドサービス技術者に、ＡＲＳラベルをどのようにして、いつ使用するのかに関する指示を与える。ある実施形態では、出荷元住所は保守部品の発生倉庫の住所であってよい。代わりに、出荷先住所は、未使用のパーツを受け取る体制が整っている場所、及び／またはその特定の保守部品の不足がある場所の住所であってよい。好適実施形態では、フィールドサービス技術者は、図１９に描かれる出荷ラベル１１０も受け取る。この例では、フィールドサービス技術者は、パーツが欠陥品、使用済み、ボックス内の誤ったパーツ、または到着時に故障している場合に図１９の出荷ラベルを使用する。代替実施形態では、追加の出荷ラベルはこれらのさまざまな状況のいくつかまたはすべてに使用されてよい。

選択可能なサービスの規則正しいリスティングを備える保守パーツ返却システム１０は、コンピュータベースのシステム、プロセッサを含むシステム、あるいは命令実行システム、装置またはデバイスから命令をフェッチし、命令を実行する他のシステムなどの、命令実行システム、装置またはデバイスによって、あるいは命令実行システム、装置またはデバイスと関連して使用するための任意のコンピュータ読み取り可能媒体で具現化できる。本文書との関連では、「コンピュータ読み取り可能媒体」は「命令実行システム、装置またはデバイスによって、あるいは命令実行システム、装置またはデバイスと関連して使用するためのプログラムを含む、記憶する、通信する、伝搬する、または輸送することができる任意の手段である場合がある。コンピュータ読み取り可能媒体は、例えば、電子、磁気、高額、電磁、赤外線、または半導体のシステム、装置、デバイスまたは伝搬媒体である場合があるが、それらに制限されない。コンピュータ読み取り可能媒体のさらに具体的な例（網羅的ではないリスト）は以下を含むであろう。つまり、１本または複数本のワイヤを含む電気接続（電子）、可搬コンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、読取専用メモリ（ＲＯＭ）（磁気）、消去可能プログラム可能ＲＯＭ（ＥＰＲＯＭまたはフラッシュメモリ）（磁気）、光ファイバ（光学）、及び過般コンパクトディスク読取専用メモリ（ＣＤＲＯＭ）（光学）である。プログラムは例えば用紙または他の媒体の光学走査を介して電子的に捕捉された後、コンパイルされ、解釈されるか、あるいはそれ以外の場合、必要な場合に適当な方法で処理されてから、コンピュータメモリに記憶されるため、コンピュータ読み取り可能媒体が、プログラムが印刷される用紙または別の適当な媒体である場合もあることに注意する。

さらに、フローチャートの任意のプロセス説明またはブロックは、プロセスで特殊な論理機能またはステップを実現するための１つまたは複数の実行可能な命令を含むモジュール、セグメントまたはコードの部分を表現すると理解されるべきであり、本発明の技術の妥当な技能者によって理解されるように、代替インプリメンテーションは、関与する機能性に応じて実質的に並列に、あるいは逆順でを含む、図示されるまたは説明されるものから順序が狂って機能が実行されてよい本発明の好適実施形態の範囲内に含まれる。

本発明の前述された実施形態、特にあらゆる「好ましい実施形態」は、本発明の原則の明確な理解のために単に述べられるインプリメンテーションの単なる例に過ぎないことが強調されるべきである。あらゆる変動及び変型が、本発明の原則の要旨から実質的に逸脱することなく本発明の前述された実施形態に加えられてよい。すべてのこのような変型及び変動は、開示及び本発明の範囲内でここに含まれ、以下の請求項により保護されることが意図される。

詳細な説明を結論付けるにあたって、本発明の原則から実質的に逸脱することなく、多くの変動及び変型を好適実施形態に加えることができることが当業者にとって明らかとなるであろうことが注記されなければならない。また、このような変動及び変型は、添付請求項に述べられるように本発明の範囲内でここに含まれることが意図される。さらに、以下の請求項では、すべての手段またはステップに加えられる機能の要素の構造、材料、動作及び同等物が、それらの引用された機能を実行するための任意の構造、材料または動作を含むことが意図される。

本発明を概略的に説明し、必ずしも一定の比例に拡大して描画されていない添付図面が参照される。
技術で既知であるような保守部品の工程系統図である。 本発明の実施形態による保守部品返却システムの高水準ブロック図である。 本発明の実施形態による保守部品返却システムのユーザが使用できる典型的なレポートである。 本発明の実施形態による保守部品返却システムの分散アプリケーションアーキテクチャを描く図である。 本発明の実施形態による保守部品返却システムの高水準工程系統図である。 本発明の実施形態による保守部品注文を処理する上で必要とされるステップを描く工程系統図である。 本発明の実施形態による保守部品注文の処理の間に記憶されているプロシジャがどのようにして呼び出されるのかを描く工程系統図である。 本発明の実施形態による保守部品注文に対する規則の適用を描く工程系統図である。 本発明の実施形態による検索前処理動作の工程系統図である。 本発明の実施形態による企業ｊａｖａビーンクライアントの呼び出しを描く工程系統図である。 本発明の実施形態による保守部品注文に対する規則の適用を描く工程系統図である。 本発明の実施形態によるデータベースの更新に備えて保守部品注文オブジェクト／データを受け取り、処理するプロセスを描く工程系統図である。 本発明の実施形態による注文データベースを更新するプロセスを描く工程系統図である。 本発明の実施形態による保守部品注文処理動作の引き取りステップ及び出荷ステップを描く工程系統図である。 本発明の実施形態による出荷ラベル印刷動作を描く工程系統図である。 本発明の実施形態による出荷ラベル印刷動作の別の工程系統図である。 本発明の実施形態によるプリンタドロップファイルの作成を描く工程系統図である。 本発明の実施形態による保守部品返却出荷ラベルを描く図である。 本発明の実施形態による別の保守部品返却出荷ラベルを描く図である。

Claims (45)

1. ユーザから、少なくとも１つの保守部品番号を含む注文データを受信する注文入力アプリケーションと、
   パーツ管理アプリケーションが前記注文データを受信し、保守部品の可用性を突き止めるために前記保守部品番号でパーツデータベースを調べることを前記注文入力アプリケーションと電子的に通信するパーツ管理アプリケーションと、
   前記注文入力システムと前記パーツ管理アプリケーションの少なくとも１つと電子的に通信する規則エンジンであって、前記注文データを受信し、少なくとも１つの規則に対照して前記注文データを処理するように構成され、前記少なくとも１つの規則に少なくとも部分的に基づいて出荷ラベルデータを生成するようにさらに構成される規則エンジンと、
   前記出荷ラベルデータに少なくとも部分的に基づいて少なくとも１枚の出荷ラベルを印刷するように構成される印刷装置と、
   を備えることを特徴とする現場の技術者に保守部品を提供するための出荷システム。
2. ユーザが前記現場の技術者であることを特徴とする請求項１のシステム。
3. 前記ユーザが、前記現場の技術者と連絡があるカスタマサービス代理人であることを特徴とする請求項１のシステム。
4. 前記注文入力アプリケーションが電子データ交換を介して前記注文データを受信することを特徴とする請求項１のシステム。
5. 前記注文入力アプリケーションが、電子メール、ファクシミリ及び電話の少なくとも１つを介して前記注文データを受信することを特徴とする請求項１のシステム。
6. 前記パーツ識別子が保守部品番号であることを特徴とする請求項１のシステム。
7. 前記パーツ管理アプリケーションが、前記保守部品を在庫に有している倉庫を特定するようにさらに構成されることを特徴とする請求項１のシステム。
8. 前記パーツ管理アプリケーションが、前記倉庫について在庫コンピュータシステムと通信し、前記保守部品が入手可能な場合に前記保守部品を確保することを特徴とする請求項７のシステム。
9. 前記パーツ管理アプリケーションが前記倉庫について在庫コンピュータシステムと通信し、前記保守部品が入手不可能である場合にそれをバックオーダすることを特徴とする請求項８のシステム。
10. 前記規則エンジンが前記注文入力アプリケーションから前記注文データを受信することを特徴とする請求項１のシステム。
11. 前記規則エンジンが前記パーツ管理システムから前記注文データを受信することを特徴とする請求項１のシステム。
12. 前記規則エンジンが運送業者規則、ロジスティクス規則及びユーザによって定義される規則の少なくとも１つに対照して前記注文データを処理することを特徴とする請求項１のシステム。
13. 前記規則エンジンがアウトバウンド出荷ラベルと返却出荷ラベルのための出荷ラベルデータを生成することを特徴とする請求項１のシステム。
14. 前記規則エンジンが第１の返却出荷ラベルと第２の返却出荷ラベルのための出荷ラベルデータを生成し、前記第１の返却出荷ラベルが返却されるパーツを使用済みと識別し、前記第２の返却出荷ラベルが前記返却パーツを未使用と識別することを特徴とする請求項１のシステム。
15. 前記規則エンジンが、現場の技術者が修理、在庫に戻すこと、廃物利用及び処分の少なくとも１つのために使用済みパーツを出荷できるようにするために返却出荷ラベルの出荷ラベルデータを生成することを特徴とする請求項１のシステム。
16. 前記印刷装置が前記規則エンジンから前記出荷ラベルデータを受信することを特徴とする請求項１のシステム。
17. 前記印刷装置が前記注文入力アプリケーション及び前記パーツ管理アプリケーションの１つから前記出荷ラベルデータを受信することを特徴とする請求項１のシステム。
18. 前記出荷ラベルデータを受信し、運送業者システムに前記出荷ラベルデータを送信し、前記運送業者システムから出荷ラベル画像を受信する倉庫アプリケーションであって、前記運送業者システムが、前記出荷ラベルデータを受信し、前記出荷ラベル画像を生成する出荷ラベル生成アプリケーションを含む倉庫アプリケーションと、
    をさらに備えることを特徴とする請求項１のシステム。
19. 前記印刷装置が倉庫に位置していることを特徴とする請求項１９のシステム。
20. 前記出荷ラベルアプリケーションが前記印刷装置に前記出荷ラベル画像を送信することを特徴とする請求項１９のシステム。
21. 前記出荷ラベルが前記出荷ラベル画像の印刷済みのコピーであることを特徴とする請求項２１のシステム。
22. 前記倉庫アプリケーションが前記出荷ラベル画像を受信し、前記印刷装置に前記出荷ラベル画像を転送することを特徴とする請求項１９のシステム。
23. 現場の技術者に出荷される保守部品のステータスを監視する方法であって、
    保守部品を現場の技術者に出荷するという要求を含む保守部品要求を受け取るステップと、
    アウトバウンド出荷ラベルと返却出荷ラベルを作成するステップと、
    前記アウトバウンド出荷ラベルに第１の保守部品追跡調査番号を、前記返却出荷ラベルに第２の保守部品追跡調査番号を割り当てるステップと、
    保守部品トランザクションデータベースで前記第１の保守部品追跡調査番号と第２の保守部品追跡調査番号とを記憶するステップと、
    前記保守部品、及び前記アウトバウンド出荷ラベルと返却出荷ラベルを前記現場の技術者に提供するステップと、
    パッケージについてのパッケージレベル詳細情報を、それが運送業者システムの中を移動するにつれて捕捉し、前記パッケージレベル詳細がパッケージ出荷ステータス及びパッケージ追跡調査番号を備えるステップと、
    前記パッケージ追跡調査番号が前記第１の保守部品追跡調査番号または前記第２の保守部品追跡調査番号に対応する場合に、前記パッケージ出荷ステータスで前記保守部品トランザクションデータベースを更新するステップと、
    を備えることを特徴とする方法。
24. 現場の技術者に少なくとも１個の保守部品を提供する方法であって、
    前記パーツに関連付けられるパーツ識別子を含む、前記現場の技術者にパーツを出荷するという注文を受けるステップと、
    前記パーツを在庫に有する倉庫の位置を突き止めるために前記パーツ識別子でパーツデータベースを調べるステップと、
    アウトバウンド出荷ラベルと少なくとも１枚の返却出荷ラベルを前記注文に関連付けるため、及び前記アウトバウンド出荷ラベル及び前記少なくとも１枚の返却出荷ラベルのために出荷ラベルデータを生成するため、規則エンジンに対照して前記注文を処理するステップと、
    前記倉庫で前記アウトバウンド出荷ラベルと前記少なくとも１枚の返却出荷ラベルを印刷するステップと、
    前記パーツとともにパッケージの中に前記少なくとも１枚の返却出荷ラベルを同封するステップと、
    前記パッケージに前記アウトバウンド出荷ラベルを貼り付けるステップと、
    前記現場の技術者に前記パッケージを出荷するステップと、
    を備えることを特徴とする前記方法。
25. 注文を受けるステップが、前記現場の技術者から注文を受けることを特徴とする請求項２５の方法。
26. 注文を受けるステップが、前記現場の技術者に関連付けられる雇用主または企業から注文を受けることを備えることを特徴とする請求項２５の方法。
27. 注文を受けるステップが、注文入力システムから注文を受けることを備えることを特徴とする請求項２５の方法。
28. 注文を受けるステップが、電子データ交換を介して注文を受けることを備えることを特徴とする請求項２５の方法。
29. 注文を受けるステップが、電子メールを介して注文を受けることを備えることを特徴とする請求項２５の方法。
30. 注文を受けるステップが、注文入力システムに注文を入力するカスタマサービス代理人によるファクシミリまたは電話呼を介して注文を受けることを備えることを特徴とする請求項２５の方法。
31. 前記注文に含まれる前記パーツ識別子がパーツ番号であることを特徴とする請求項２５の方法。
32. 倉庫を特定するためにパーツデータベースを調べるステップが、前記パーツの可用性及び場所を突き止めるためにパーツデータベースを調べることを備えることを特徴とする請求項２５の方法。
33. 倉庫を特定するためにパーツデータベースを調べるステップが、
    前記パーツを在庫に有する倉庫の場所を突き止めるステップと、
    前記パーツを確保するために在庫データベースでフラグをセットするステップと、
    前記パーツを出荷のために採取させるために前記倉庫に連絡するステップと、
    を備えることを特徴とする請求項２５の方法。
34. 倉庫を特定するためにパーツデータベースを調べるステップが、前記パーツが入手可能であるのかを判断するためにパーツデータベースを調べることと、入手可能ではない場合に、前記パーツをバックオーダすることとを備えることを特徴とする請求項２５の方法。
35. 規則エンジンに対照して前記注文を処理するステップが、
    企業Ｊａｖａビーンクライアントを介して企業Ｊａｖａビーンに提出するために前記注文を注文アレイに変換するステップと、
    前記企業Ｊａｖａビーンの中に前記注文アレイを受け入れるステップと、
    前記規則エンジンによる処理に適したＪａｖａ注文オブジェクトを作成するステップと、
    前記注文オブジェクトを前記規則エンジンに渡すステップと、
    を備えることを特徴とする請求項２５の方法。
36. 規則エンジンに対照して前記注文を処理するステップが、運送業者規則、ロジスティクス規則、及びユーザにより定義される規則の内の少なくとも１つを前記注文に適用することを備えることを特徴とする請求項２５の方法。
37. 前記少なくとも１枚の返却出荷ラベルのために出荷ラベルデータを生成するステップが、第１の返却出荷ラベルと第２の返却出荷ラベルのためにラベルデータを生成することを備え、前記第１の返却出荷ラベルが返却されるパーツを使用済みと識別し、前記第２の返却出荷ラベルが前記返却されるパーツを未使用と識別することを特徴とする請求項２５の方法。
38. 前記少なくとも１枚の返却出荷ラベルのために出荷ラベルデータを生成するステップが、前記倉庫に前記パーツを返却するために使用される返却出荷ラベルのためのデータを生成することを備えることを特徴とする請求項２５の方法。
39. 前記少なくとも１枚の返却出荷ラベルのために出荷ラベルデータを生成するステップが、前記現場の技術者が前記倉庫に前記パーツを返却できるようにするために出荷ラベルのためのデータを生成することを備えることを特徴とする請求項２５の方法。
40. 少なくとも１枚の返却出荷ラベルのための出荷ラベルデータを生成するステップが、前記倉庫を前記出荷ラベルの宛て先住所として指定する出荷ラベルのためにデータを生成することを備えることを特徴とする請求項２５の方法。
41. 前記少なくとも１枚の返却出荷ラベルのための出荷ラベルデータを生成するステップが、前記現場の技術者が、修理、在庫に戻すこと、廃物利用、及び処分の少なくとも１つのために使用済みのパーツを出荷できるようにするために１枚または複数枚の出荷ラベルのためのデータを生成することを備えることを特徴とする請求項２５の方法。
42. 前記アウトバウンドラベルと前記少なくとも１枚の返却出荷ラベルを前記倉庫で印刷するステップが、
    前記倉庫に位置する印刷装置に電子フォーマットで前記出荷ラベルデータを送信することと、
    前記印刷装置を介して前記アウトバウンドラベルと前記少なくとも１枚の返却出荷ラベルを印刷し、前記少なくとも１枚の出荷ラベルが前記出荷ラベルデータに少なくとも部分的に基づくことと、
    を備えることを特徴とする請求項２５の方法。
43. 前記倉庫で前記アウトバウンドラベル及び前記少なくとも１枚の返却出荷ラベルを印刷するステップが、
    前記倉庫と関連付けられるコンピュータシステムに電子フォーマットで前記出荷ラベルデータを送信することと、
    前記倉庫コンピュータシステムの手動起動時に運送業者アプリケーションに前記出荷ラベルデータを転送することと、
    前記アウトバウンド出荷ラベル及び前記１枚または複数枚の出荷ラベルのそれぞれにパッケージ追跡調査番号を割り当てることと、
    前記アウトバウンド出荷ラベルと前記少なくとも１枚の返却出荷ラベルを、前記出荷ラベルデータに少なくとも部分的に基づいて作成することと、
    前記倉庫で前記アウトバウンド出荷ラベル及び前記少なくとも１枚の返却出荷ラベルを印刷することと、
    を備えることを特徴とする請求項２５の方法。
44. 第１の追跡調査番号を前記アウトバウンド出荷ラベルに、第２の追跡調査番号を返却出荷ラベルに割り当てるステップとをさらに備えることを特徴とする請求項２５の方法。
45. 前記パーツとともにパッケージ内に前記少なくとも１枚の返却出荷ラベルを同封するステップが、
    前記倉庫内の保管領域から前記パーツを採取するステップと、
    前記パーツをパッケージに入れるステップと、
    印刷装置から前記少なくとも１枚の返却出荷ラベルを検索するステップと、
    前記パッケージに前記少なくとも１枚の返却出荷ラベルを同封するステップと、
    を備えることを特徴とする請求項２５の方法。
    

Images