JP2006503352A - プランニング、スケジューリングおよびサプライ・チェーン・マネジメントを改善するためのシステムおよび方法 - Google Patents

Abstract

本発明は、プラニング、スケジューリングおよびサプライ・チェーン・マネジメントを改善するためのシステムおよび方法に関する。本発明のいろいろな実施例は、サプライチェーンにおいて異なるタイプのアイテムの在庫を管理するためのシステムおよび方法を提供する。本発明の1つの面は、サプライチェーンにおいて類似するアイテムの在庫を管理する方法に焦点を合わせる。前記方法は、フローパスが少なくとも1つのオペレーションを含むサプライチェーンにおいてアイテムに関してフローパスを決定することを含む。前記方法はまた、各々のオペレーションでアイテムに関して在庫データを受け取ること;前記在庫データを記憶すること；前記アイテムに関して需要要因を決定すること；および前記アイテムに関してコスト要因を決定することを含む。前記方法はさらに、前記需要要因と前記コスト要因に部分的に基づいて、前記アイテムに関してイクスチェンジ・カーブを決定すること；および前記イクスチェンジ・カーブと前記アイテムに関して在庫データの一部を表示することを含む。

Description

本発明は、一般にプラニング、スケジューリングおよびサプライ・チェーン・マネジメントを改善するためのシステムおよび方法に関する。

カスタマー・サプライチェーン要求を扱うための従来のシステムおよび方法は、通常は以下の方法のうちの1つに合わされる。第一に、単純な経験則が使用されうる。多くの会社は、特に小規模会社は、プラニングおよびスケジューリングのために単純な経験則を使用する。「見込み購入」タイプ会社では、例えば、各購入部品に関して、在庫が「およそ一週間分」を下回ると、「一ヵ月分」を注文する。これらのタイプの単純なルールは比較的覚え易くそして実行し易いが、それらは一般的に結果として貧しい在庫管理成績を導く。しばしば、在庫は全体としては過剰だが、多くの「品切れ」が起こる。特定のアイテムに対する在庫が、そのアイテムに対するカスタマー・オーダーまたは需要を満たす、または需要に合致するには不十分であるとき、「在庫切れ」が現実となる。

次に、内部資源によって開発されカスタマイズされたソフトウェアが、使用されうる。いくつかの会社は、単純な経験則を改善するために、社内システムを開発した。この種の社内システムは、使用される特定の産業および生産技術のためにしばしばカスタマイズされる。この種のシステムの少なくとも1つの重大なマイナス面は、多くが時々旧式なハードウェアを使用する古いプラットホームで開発されたということである。これらのレガシー-タイプ・システムはより新しいテクノロジーとのインターフェースが難しく、そしてシステムのメンテナンスまたは強化に時間がかかり費用も高くつく。

他の従来のシステムは、外部資源によって開発されカスタマイズされたソフトウェアを含む。上記のオプションのこのバリエーションは、開発および維持管理費用を増やしうる。

次に、従来のシステムは、パッケージ化されたソフトウェア（例えば、エンタープライズ・リソース・プランニング（ERP）、資材所要量計画（MRP）またはサプライ・チェーン・マネジメント（SCM）アプリケーション・プログラム）を含む。いくつかの製造会社は、ERPおよび／またはSCMパッケージを利用するステップをとった。ERPおよびMRPパッケージは幅広い機能を提供するが、それらはプラニングおよびスケジューリングが不得意である。そして、SCMパッケージがサプライ・チェーン・マネジメントを改善する一方、フルスケールのSCM/ERPパッケージは重大な投資および実施コスト（通常100万米ドルを上回る）を必要とする。ERPベンダーは、このエリアにおいてそれらの機能を改善するために、カスタマーおよび競争者からますます圧力を受けている。ERPベンダーは、それら既存のERPパッケージにおける問題を解決し、かつSCMベンダーの最高の組合せと競争する必要がある。

エンタープライズ・リソース・プランニング（ERP）システムには、アドバンスド・プランニング・アンド・スケジューリング（APS）システムの有無にかかわらず、ロジスティックスを作るとなると、多くの問題がある。これらの問題は以下を含む：(1)サイクル・タイムはERPの一部の機能であると考えられるが、実際には、ラインの中に存在する作業量、ラインのキャパシティ、未加工−工程所要時間および変動に依存する。MRP-タイプ・システムの開発でとられるいろいろなショートカットは、最も包括的なERPシステムにおいてさえ、これまで適切に扱われなかった;(2)キャパシティチェックが一斉になされる代わりに、重要なプランに対して特別に実行されること;(3) アドバンスド・プランニング・アンド・スケジューリング（APS）システムは、悪名高く複雑でそして絶えず最新でなければならない莫大な量のデータを必要とする−さらに、多くのAPSがMRPモジュールの出力を取りそして混乱が最小になるようにスケジュールすることを試みるが、これおよび他のアプローチは、様々な点で「あまりに小さく、あまりに遅い」。(4)MRP/APSアプローチは、本質的に「プッシュ」であって、それゆえ逃した製造機会だけでなく、仕掛品（WIP）およびサイクル・タイムの急激な増加に影響されやすい。

在庫サイズを決定する従来のシステムおよび方法は、いくつかの難しい計算（例えば、リオーダ点およびリオーダ量を決定する）に直面する。「見込生産」または「注文生産」の決定は、一般的に「ユーザ入力」パラメータである。つまり、ユーザはリオーダ点およびリオーダ量と関連するパラメータを決定すること、さもなければ入力することを要求される。同様に、安全在庫および／または発注量はそれ自身、ユーザ入力と考えられる、あるいは「オーダー・コスト」および「在庫維持コスト」のようなパラメータはユーザ入力である。多くの場合、ユーザにはそのようなパラメータを決定するための直観力がほとんどない。最適なリオーダ点およびリオーダ量をセットすることは、多くの会社にとって能力が試される。あまりにたくさんの材料がストックされるならば、その会社はあまりにたくさんの在庫を持つだろう。そして、高い投資と低い総資産利益率に終わる。十分な材料がストックされないならば、カスタマーの不満、オーダーのキャンセルおよび／または販売の喪失をしばしば結果として導く「品切れ」が起こるかもしれない。さらに、適切なタイミングで材料をオーダーすることは、他のレベルの複雑さを加える。しかし、問題を特に能力が試されるものにしていることは、大部分の会社が対処するパラメータが古典的な在庫分析において使用されるパラメータと同じでないということである。

さらにまた、多くの会社は、何百または何千もの製品を管理しなければならない。これらの各々は、リオーダ点とリオーダ量を必要とする。会社は、これらのポリシーを最適化すること、およびひどい結果をもたらす単純な「経験則」に頼ることがしばしばできない。例えば、多くの会社は、何週間にも及ぶ供給目標に基づくリオーダ量をセットする;その結果、それらはいくつかの製品に関してあまりにたくさんの在庫を持ち、一方、他の製品に関して在庫切れを起こす。ゆえに、多くの会社にとって能力が試される問題は、総在庫投資がある程度の集積されたサービスに関して最適化されなければならないということである。

在庫サイズを決定するいくつかの従来のシステムおよび方法は、ユーザがパラメータ（例えばオーダー・コストとバックオーダ・コスト）を知っていると仮定する。しかし、これらのパラメータは、計算したり、状況を常に把握することがしばしば難しい。それゆえに、サプライチェーンの中で類似したアイテムの在庫を管理するシステムおよび方法に対するニーズが存在する。

多くの従来の製造システムにおいて、商品またはアイテムは、複数パートから成る。プラント切り換えタイムおよび／またはコストを許容できるレベルに下げられるように、同じタイプのパーツはロットで処理している。しかし、比較的大きなサイズのロットは、サイクル・タイムにおける分散と同様に平均サイクル・タイムを増加する可能性がある。十分に長いロット（資源の効率的利用を確実にする）と、十分に短いロット（仕掛品（WIP）レベルを低くし比較的滑らかに流れるシステムを維持する）との間には微妙なバランスがある。「仕掛品」は、完全に製造されておらずまだ完成されていない製品またはアイテムの量と、定義される。

多くのAPS'sは、サイクル・タイム短縮の重要な問題に直接取り組まない。ロット・サイズは、サイクル・タイムの平均と分散に重要な影響を及ぼす可能性がある。「ロット・サイズ」は、一度に作り出される部品または材料の定義された量として、ここに定義される。いくつかの従来のシステムと方法は、セットアップ「コスト」と保管コストを考慮するモデルに基づくロット・サイズを計算する。セットアップ・コストは通常限られた能力の代わりであるので、そして、古典的なロットサイズ・アプローチ（例えばWagner-Whitin）は能力を考慮しないので、結果として生じるロット・サイズはサイクル・タイムを低くしておくために役に立たない。他のシステム（例えばi2のFactory Planner）は、入力としてロット・サイズ値を必要とする。適切なロット・サイズは時々、サイクル・タイムを減らすことにきわめて重大で、まったく直観的でない。

ERPシステムのようなレガシー・タイプ・システムは、従来のロット・サイズ決定アルゴリズム（例えばlot-for-lot、パートピリオドバランシング、グルフ方法、最適発注量、その他）を利用する。一般的に、これらは「見込生産」商品とアイテムによい。しかし、従来のロット・サイズ決定アルゴリズムは、サイクル・タイムを最小にするように設計されていない。

ERPシステムとパッケージは、一般的に、企業をプラニング、スケジューリング及びサプライ・チェーン・マネジメントで手助けするために、一つ以上のモジュールを備えている。一般的に、これらのモジュールは、もとは、Materials Requirements Planning（MRP,資材所要量計画）と呼ばれている1970年代に開発されるテクノロジーの上に築き上げられている。MRPは、企業が原材料及び他の入力のために期日を決定するのを手助けするためにつくられた。残念なことに、前提条件（例えば無限の能力及び固定されたリード・タイム）に苦しんで、MRPは複雑な生産環境のために良いスケジュールを生み出さない。その結果、MRPは機能性を加えるために、長年にわたってアップデートされ、修正されていた。1980年代に、容量計画機能性を含めて、Manufacturing Resource Planning（MRP-II）として市場に出された。更なる特徴が、主に庶業機能と融和するために、1990年代に追加され、Enterprise Resource Planning（ERP）と呼ばれた。過去２、３年に、ERPベンダーは、一般にAdvanced Planning and Scheduling（APS）と呼ばれているさらなるソフトウェアを市場に出した。APSは有限能力スケジューリング及び他のツールでMRP論理を補うが、それは弱い基盤の上に築き上げられている。

ますます、ERP顧客はERP導入に対する失望を表明した、そして、主要なERPベンダーの収益と時価総額は急速に下落している。販売の下落は、以下の他の要素によっても、生じた：(1)レガシー・システムがY2Kに対応しておらず、多くのERPパッケージが1990年代後期にインストールされたため、2000年問題に備えて支出が削減された；(2)ERPパッケージがとても幅広いので、それらはそれらがサポートするすべてのビジネス機能の中で最高の機能を提供することを望めないという「最善の組合せの」ソフトウェアの増大。近年、ニッチ機能での最善の組合せベンダーからの販売が急増した。いくつかの顕著な例は、カスタマー・リレーションシップ・マネジメントのシーベル・システムとサプライ・チェーン・マネジメントのi2テクノロジーズである。

顧客は、ますます彼らのビジネス機能をインターネット使用可能なインターフェースと取引パートナーにつなぎたい。しかし、ERPパッケージは、ベンダー固有のデータベース構造上に築き上げられており、それが彼らの技術基盤を弱め、そして最善の組合せのベンダーから更なる競争を招くので、ERPベンダーはこれらの標準をオープンにするのが遅かった。ERPベンダーは、ますますウェブ・サービスとデータベース統合のための新興のデファクトスタンダード（例えばSun's J2EEまたはMicrosoft's .NET）のうちの1つと連携する方に押しやられる。

プランニング・アンド・スケジューリングでのERPの弱点があれば、多数の企業は、プラニング、スケジューリングとサプライ・チェーン・マネジメントを改善するように特に手直しされたソフトウェアを作成した。これらの「最善の組合せの」ベンダーは、より大きなERPパッケージおよび／またはレガシー・システムに「追加」可能なプランニング・アンド・スケジューリング・パッケージを販売する。1990年代後期のベンダーのこの新しい種類の高まりは、サプライ・チェーン・マネジメント（SCM）と呼ばれている新しい市場区分をつくった。これらのベンダーは、以下のようにしてERP弱点を利用している：
・ 上記のように、ERPのSCMモジュールは、その制限前提条件を伴って、MRPの上に通常は築き上げられる。SCMベンダーは、このレガシー・インフラストラクチャで拘束を受けていない革新的なアルゴリズムを開発することができる。

・ 大部分の大きなERPパッケージは18-24ヵ月のリリース・サイクルを持つ、そして小さいSCMベンダーほど速く、また多くの分野で革新することを望むことができない。

・ ERPソフトウェアは、しばしば顧客にそのソフトウェアにフィットするように彼らの仕事を適応させることを強制する。SCMパッケージはより限られた適用範囲を持ち、したがって、顧客の現在のビジネス・プロセスに合うようにより簡単に手直しされ、構成されることができる。

・ ERPは、効果的なリポーティングのためではなく、効率のよいトランザクションのために造られる。SCMパッケージは、レガシーERPシステムにしばしばすでに集められ保存されたデータを報告することに集中することができる。SCMベンダーは、ERPデータベースにすでに保管されているデータをますます利用することができる。

1990年代におけるERP増加の要因の1つは、大企業からの全てのデータを一つ（モノリシックデータベース）に統合整理するその能力であった。しかし、近年、統合技術は、企業が、ERPデータベースに保管されているデータを、特定のビジネス機能のために設計された他のアプリケーションと統合することをより簡単にした。SCMベンダーは、したがって、ERPによってすでに提供されているデータ収集インフラストラクチャを造ったりサポートすることなく、プランニング・アンド・スケジューリングを改善するための機能に集中することができる。

しかし、プラニング、スケジューリング及びサプライ・チェーン・マネジメントを改善するシステム及び方法に対するニーズが、存在する。サプライチェーンにおいて類似したアイテムの在庫を管理するためのシステム及び方法に対する更なるニーズが、存在する。サプライチェーンにおいて異なるタイプのアイテムの在庫を管理するためのシステム及び方法に対するニーズも、存在する。サプライチェーンにおいて多様なタイプのアイテムのロット・サイズを管理するためのシステム及び方法に対するニーズが、存在する。サプライチェーンにおいて類似したアイテムに関するストッキング・ポリシーを決定するためのシステム及び方法に対するニーズも、存在する。サプライチェーンにおいて異なるタイプのアイテムに関するストッキング・ポリシーを決めるシステム及び方法に対するさらに別のニーズが、存在する。さらに、サプライチェーンにおいて多様なタイプのアイテムのロット・サイズを管理するシステム及び方法に対するニーズが存在する。さらにまた、入って来る注文に対する約束日を決定するシステム及び方法に対するニーズが存在する。「約束日」は、注文した品がいつ完了するかを予測するために使用される期待完成日として定義され、そして、それは配送のコミットメント又は約束として伝えられるかもしれないし、又は伝えられないかもしれない。多様なタイプのアイテムのためのサプライチェーンを管理するシステム及び方法に対するニーズも、存在する。

本発明のいろいろな実施例のシステム及び方法は、上記の問題及びそれらの組合せの一部または全部を扱う。それらは、プラニング、スケジューリング及びサプライ・チェーン・マネジメントを改善するシステム及び方法を提供することによってそうする。さらに、本発明のいろいろな実施例は、サプライチェーンにおいて類似したアイテムの在庫を管理するシステム及び方法を提供する。本発明の1つの面は、サプライチェーンにおいて類似したアイテムの在庫を管理する方法に焦点を合わせる。その方法は、フローパスが少なくとも1つのオペレーションから成るサプライチェーンにおいてアイテムのフローパスを決定することを含む。その方法は、各々のオペレーションでアイテムの在庫データを受け取ること;在庫データを格納すること;アイテムの需要要因を決定すること;及びアイテムのコスト要因を決定することを含む。その方法は、需要要因及びコスト要因に一部基づき、アイテムのイクスチェンジ・カーブ(exchange curve)を決定すること;及び、イクスチェンジ・カーブ及びアイテムの在庫データの一部を示すことを含む。

発明のもう一つの特定の面は、サプライチェーンにおいて異なるタイプのアイテムの在庫を管理する方法を含む。その方法は、オペレーションで第１のタイプのアイテムに関して在庫データを受け取ること;オペレーションで第2のタイプのアイテムに関して在庫データを受け取ること;及び第１のタイプ及び第2のタイプのアイテムに関して在庫データを記憶することを含む。その方法はまた、第１のタイプ及び第2のタイプのアイテムに関して需要要因を決定すること;第１のタイプ及び第2のタイプのアイテムに関してコスト要因を決定すること;及び、需要要因及びコスト要因に部分的に基づいて第１のタイプのアイテムに関する第１のイクスチェンジ・カーブ及び第２のタイプのアイテムに関する第２のイクスチェンジ・カーブを決定することを含む。さらに、その方法は、第１および第２のタイプのアイテムに関するイクスチェンジ・カーブと第１および第２のタイプのアイテムに関する在庫データの一部を示すことを含む。

発明のもう一つの面は、少なくとも1つのステーションを含むサプライチェーンにおいて類似したアイテムのロット・サイズを管理する方法を含む。その方法は、第１のステーションでアイテムのために最初のロット・サイズを決定すること;各々のステーションでアイテムのためにルーティング・データを受け取ること;及びルーティング・データを記憶することを含む。さらに、その方法は、ルーティング・データに基づいて、第１のステーションからサプライチェーンを通して流れているアイテムに関してサイクル・タイムを決定すること;及びサプライチェーンを通して第１のステーションから流れているアイテムに関するサイクル・タイムに少なくとも基づいて、そのアイテムに望ましいサイクル・タイムを選択することを含む。その方法はまた、アイテムのために選択された望ましいサイクル・タイムに少なくとも基づいて、第１のステーションでアイテムのために最初のロット・サイズを調整することを含む。

発明のもう一つの特定の面は、少なくとも1つのステーションを含むサプライチェーンにおいてアイテムの複数タイプのロット・サイズを管理する方法である。その方法は、第１のステーションで第１のタイプのアイテムに関して最初のロット・サイズを決定すること;第１のステーションで第2のタイプのアイテムに関して最初のロット・サイズを決定すること;アイテムが第１のステーションからサプライチェーンを流れるとき各々の種類のアイテムに関してルーティング・データを受け取ること;及びルーティング・データを記憶することを含む。その方法はまた、ルーティング・データに基づいて、第１のステーションからサプライチェーンを流れている各々のタイプのアイテムに関してサイクル・タイムを決定すること;及び、第１のステーションからサプライチェーンを流れているアイテムのためのサイクル・タイムに少なくとも基づいて、各々のタイプのアイテムに関して望ましいサイクル・タイムを選択することを含む。さらに、その方法は、各々のタイプのアイテムにとって望ましいサイクル・タイムに少なくとも基づいて、第１のステーションで各々のタイプのアイテムに関して最初のロット・サイズを調整することを含む。

発明のさらにもう一つの面は、サプライチェーンが少なくとも1つのステーションを含み、入って来る注文に対する約束日を決定する方法を含む。その方法は、ステーションでアイテムのために生産時間を決定すること;ステーションでアイテムのためにセットアップ時間を決定すること;及び累積的な有効キャパシティ(available capacity)を決定することを含む。その方法はまた、予約されたキャパシティ(booked capacity)を決定すること;累積的な有効キャパシティ及び予約されたキャパシティの違いを決定して、及び少なくともそのステーションでのアイテムのための生産時間及びそのステーションでのアイテムのためのセットアップ時間によって違いを調整すること;及び、その違いに部分的に基づいて、入って来るオーダーのために最小限のリード・タイムを決定することを含む。

発明のもう一つの面は、複数のタイプのアイテムのためにサプライチェーンを管理する方法である。その方法は、各々のフローパスがオペレーションを含むサプライチェーンにおいて各々のタイプのアイテムのためにフローパスを決定することを含む。その方法は、各々のオペレーションで各々のタイプのアイテムのために性能データを受け取ること;その性能データを記憶すること;他のストッキング・ポリシーにおけるトレードオフを示しているイクスチェンジ・カーブ、ロット・サイズ最適化とWIPレベル・トレードオフ・カーブ、及び約束日から成るグループから選ばれる決定を得るためにその性能データを処理すること;及びそのアイテム及びその決定のためにその性能データの一部を示すことを含む。

その発明のいろいろな実施例によるいろいろなシステム及び方法の特徴および効果は、以下を含む：
(1)プラニング、スケジューリング及びサプライ・チェーン・マネジメントを改善するためのシステム及び方法を提供すること;
(2) サプライチェーンの中で類似したアイテムの在庫を管理するためのシステム及び方法を提供すること;
(3) サプライチェーンの中で異なるタイプのアイテムの在庫を管理するためのシステム及び方法を提供すること;
(4) サプライチェーンの中で類似したアイテムのストッキング・ポリシーを決めるためのシステム及び方法を提供すること;
(5) サプライチェーンの中で異なるタイプのアイテムのストッキング・ポリシーを決めるためのシステム及び方法を提供すること;
(6)サプライチェーンの中で複数のタイプのアイテムのロット・サイズを管理するためのシステム及び方法を提供すること;
(7)サプライチェーンの中で複数のタイプのアイテムのロット・サイズを管理するためのシステム及び方法を提供すること;
(8) 入って来るオーダーに対する約束日を決定するためのシステム及び方法を提供すること;及び
(9)複数のタイプのアイテムのためにサプライチェーンを管理するためのシステム及び方法を提供すること。

本発明のシステム及び方法のいろいろな面及び実施例の他の特徴および効果は、この文書の他の部分から明らかである。本発明は、ここに含まれる以下の詳細な説明を参照することによって、より容易に理解されるであろう。本発明はそれらのある実施例の特定な詳細に関して記述されたが、そのような詳細は本発明の適用範囲への制限とみなすべきものと意図されたものではない。ここで言及した全てのリファレンスの全テキストは、参照によって全体としてここに組み入れられる。

本発明は、一般に、プラニング、スケジューリング及びサプライ・チェーン・マネジメントを改善するためのシステム及び方法を提供することに関する。本発明の好ましい実施例によれば、システムはフロー・パス・マネジメント・システム(Flow Path Management System; FPMS)またはサプライチェーン・マネジメント・システム（SCMS）として記述される。本発明のシステム及び方法は、それ自体によっておよび／またはエンタープライズ・リソース・プランニング(Enterprise Resource Planning；ERP)システムまたはサプライ・チェーン・マネジメント（SCM）システムと組み合わせたFPMSに関するものでもよい。さらにまた、本発明のシステム及び方法は、FPMSの範囲内だけのモジュールまたはそれらのモジュールの組合せに関するものでもよい。たとえば、これらのモジュールは、順序制御、在庫アドバイザー（IA）、ファーストタイムスルー(first time through)、ロット・サイズ及び仕掛品エスティメータ（LWE）及び約束日ファインダー（PDF）を含むが、それらに制限されない。一般に、顧客期日を満たしている間、順序制御モジュールは切替タイムを最小にするためにシーケンス生産命令に向いている。ファーストタイムスルーモジュールは、品質の問題及び修正処置を報告するために使用される。在庫アドバイザー・モジュールは、どの製品が受注生産でなければならないか、どれが見込生産でなければならないか決定するのに用いられる。在庫アドバイザー・モジュールはまた、見込生産製品のためのリオーダ点及びリオーダ量を決める。LWEモジュールは、(a)圧迫された資源を特定し、（b）アウトプットのゴールを満たしている間、セットアップを最小にするためにいくつの製品が一緒に作り出されなければならないかを最適化し、そして(c)スループット及びサイクル・タイム目標に達するために、WIPレベルを最適化する。PDFモジュールは、入って来るオーダーのリード・タイムを決めるために用いられる。

本発明のシステム及び方法は、さまざまな方法で顧客に提供されるかもしれない。たとえば、本システム及び方法は、スタンドアロン・システムとしてまたは既存のスタンドアロン・システムの一部として提供されるかもしれない。本システム及び方法は、また、ネットワーク（例えばイントラネット、ローカル・エリア・ネットワークまたはワイド・エリア・ネットワーク）上で提供されうる。また本ネットワークは、ワイヤレス・ネットワーク（例えばモバイル無線電話網、無線データ通信ネットワーク、衛星ネットワーク、その他）を含む。このように、ユーザはパソコン、パーソナル・ディジタル・アシスタント（PDA）、ポケットPC、パーム・デバイス、3Gデバイス、WAP使用可能な電話、WebTV及び他のデータ、コミュニケーションまたはエンタテインメントデバイスを含むさまざまな方法で、本発明のシステム及び方法にアクセスすることができる。さらにまた、本システム及び方法は、インターネット（たとえばアプリケーション・サービス・プロバイダー（ASP）など）を通して、顧客に提供されうる。本システム及び方法は、販売、ライセンス供与、レンタル、その他の方法でユーザに提供されるかもしれない。

本システム及び方法のユーザは、製造業タイプの企業のバイヤー、プランナー及びスケジューラーを含むが、これらに限定されない。一般に、これらの企業の一部または全部は、「見込購入」企業、「見込生産」メーカー及び「受注生産」メーカーに分類することができる。これらの顧客及びユーザは単に典型的なものだけであり、本発明は本システム及び方法から利益を受けるかもしれない他のタイプのユーザ、企業及び他のエンティティを取り込む。

多くの実例において、サプライチェーンはフローパスの集合となる。「フローパス」は、ここに定義される商品またはアイテムが流れる資源のネットワークである。パーツが指定のパスにおける重複点で出入り可能ということにおいて、フローパスがフローラインよりも一般的であることに留意する。一つ以上のフローパスを選んで、それからフローパス動作のモデルを開発することによって、強力で、有効な生産計画システムがモデル化される。フローパス、モデル、及び生産計画のために実行される関連ソフトウェアの指定は、フローパス管理システムを作る。

本発明の実施例によるフローパス管理システムが、在庫のストックから販売する卸売り/小売オペレーションに焦点を合わせること、そしてまた一方向性フローパス（すなわちフローパスに沿った一方向だけの部品フロー）を持つ製造および／またはアセンブリを含んでいる製造オペレーションにも焦点を合わせることに注意する。この種の「一方向性」フローパス環境は、アルミニウム圧延工場から製薬プラントまでの、幅広い範囲の製造タイプ企業を含む。

FPMSのフローパス管理機能性は、許可されたユーザが単数または複数のフローパスを定義するのを許す。ユーザは所定のプラントで全ての製品またはアイテムの利用可能なセットから製品またはアイテムの群（またはサブセット）を選ぶことによってこれをして、そのうえ製造プロセスにおいて製品またはアイテムのそのサブセットによって訪ねられるワーク・センターのグループ（またはサブセット）を選ぶ。

これらの製品（またはアイテム）とワーク・センターは、特定のプラントの全ての製品（またはアイテム）とワーク・センターの母集団（利用可能な）セットから選ばれる。フローパス定義は、特に製品またはアイテムの所定のサブセットがそれらの生産サイクルの中で複数のプラントを経由する場合、一つのプラント適用範囲を含むが、それに限定されない。一例として、フローパスの定義は、次のように表されうる：

k =あるプラントで生産された製品またはアイテムの合計数
n =あるプラントのワーク・センターの合計数
r=1,2,3,...
P =あるプラントの全ての製品またはアイテムの母集団
Pi=製品またはアイテムの離散サブセット
WC =あるプラントのワーク・センターの母集団
WCj =ワーク・センターの離散サブセット
FP =全ての定義されたフローパス;
FPr =ワーク・センターのサブセットを訪ねる製品またはアイテムのサブセットによって定義された離散フローパス
もし

（排他−製品またはアイテムは、1つのフローパスだけに属することができる）。言い換えると、フローパスは製品とワーク・センターの関数である、製品またはアイテムの離散集合が製造プロセスを通じてワーク・センターの離散数と交わる（訪ねる）ように。

「製品」、「商品」及び「アイテム」全て、プラントで製造されるであろう又は製造されている物に言及することに注意する。用語（「製品」、「商品」及び「アイテム」）は、明細書のテキストを通して、同義的に使用される。「ワーク・センター」がまた、「オペレーション」または「ステーション」とすることができ、そして、これらの用語がまた、明細書のテキストを通して同義的に使われることに注意する。

本発明に従ってさまざまなシステムが、造られうる。図1は、本発明の典型的な実施例が動作することになる典型的なシステム100を例示している図である。本発明は、同様に他システムで動作し、具体化されうる。添付の図面の中で示されるように、参照は本発明の典型的な実施例で詳細にされる。同一又は類似の部分に言及するために、図面及び以下の説明を通して、同じ参照番号が、使われる。

発明のさまざまな実施例によるシステム100の例は、ネットワーク化されたコンピュータ環境のコンテキストの中で例示される。本発明のさまざまな実施例による他のシステムが実行可能な他の環境が存在する。示されるシステム100は、コンピュータ・ネットワーク102とともに動作するのに適しているフローパス管理システムである。システム100は、フローパス管理システム（FPMS）サーバ104、リレーショナル・データベース106及びウェブサーバ108を含む。本発明のさまざまな実施例に従うシステムにおいて他の構成要素が存在してもよい。

フローパス管理システム（FPMS）サーバ104は、メモリ114に記憶されるFPMSアプリケーション・プログラム112といった一つ以上のソフトウェア・プログラム・モジュールを実行するプロセッサ110を含む。FPMSアプリケーション・プログラム112は、プランニング、スケジューリング及びサプライ・チェーン・マネジメントを改善するのに適している一組のコンピュータ実行可能な命令またはソフトウェア・プログラムである。FPMSアプリケーション・プログラム112は、一つ以上のプログラム・モジュール、例えば在庫アドバイザー（IA）、ロット・サイズ及び仕掛品（WIP）エスティメータ、約束日ファインダー（PDF）、シーケンシング及びファーストタイムスルーなどを含むことができるが、それらに限定されない。これらのモジュールの各々は、サプライチェーン・プランニング・ツールを提供する。FPMSアプリケーション・プログラム112のいろいろなモジュールのいくつかまたは全てが同じまたは異なるプロセッサー・ベースのプラットホームから実行及び操作することができる。FPMSアプリケーション・プログラム112は、どんなプロセッサに基づくプラットホーム（例えばFPMSサーバ104、別のサーバ、クライアント116または離れて位置するプロセッサー・ベースのデバイス）でも作用することができる。

FPMSサーバ104は、リレーショナル・データベース106のような一つ以上のデータベースまたはデータ記憶装置と通信している。さらに、FPMSサーバ106は、またネットワーク102、インターネット、イントラネットまたは別のネットワークと通信している。リレーショナル・データベース106によってまたはネットワーク102によって、FPMSサーバ104は、クライアント116を動かしている少なくとも1人のユーザから、いろいろなデータ入力を受け取る。データ入力がまた、ユーザがクライアント116にいろいろなデータを選んで、入力する選択データ入力でありえる点に注意する。データ入力及び選択データ入力は、“データ入力”または“選択データ入力”としてひとまとめにして言及される。データ入力は、需要情報、供給情報及びサプライチェーン情報を含むことができるが、それらに限定されない。メモリ114および／またはリレーショナル・データベース106は、ネットワーク102を介してまたは直接別のソースから受け取られるデータ入力を格納する。データ入力の他のタイプは、また、本発明のいろいろな実施例によれば、FPMSサーバ104及びその関連部品によって引き出されて、確かめられるか、さもなければ受け取られて、それから保存されることができる。

ウェブサーバ108は、FPMSサーバ104及びネットワーク102と通信している。ウェブサーバ108は、ネットワーク102を経てデータ入力を受信するためにウェブサイト118のホストをつとめるのに適している。ウェブサーバ108は、プロセッサ120及びメモリ122を含む。一般に、ウェブサイト118はネットワーク102を経てウェブサーバ108と通信する一つ以上のクライアント116によってアクセスできる。

クライアント116は、ブラウザ・アプリケーション・プログラム124（例えばマイクロソフトのInternet Explorer（商標）、バージョン6.0; ネットスケープコミュニケーションズコーポレーションのNetscape Navigator（商標） バージョン7.1;及びアップルコンピュータのSafari（商標）、バージョン1.0またはウェブサイト118の閲覧またはアクセス機能を有する他のタイプのブラウザ・プログラム)を実行する。ユーザは、ウェブサイト118を見るためにブラウザ・アプリケーション・プログラム124を利用するために、クライアント116にアクセスすることができる。ユーザからのデータ入力は、クライアント116に含まれる入力装置126によって入れられることができる。入力装置は、マウス、タッチパッド、キーボード、タッチスクリーン、ポインター、音声認識、スキャナ、バーコードリーダまたは類似タイプの入力装置を含むが、これに限定されない。一つ以上のクライアント116がネットワーク102、ウェブサーバ108、直接的な接続性、無線通信、インターネットまたは他の通信タイプ・ネットワークを通じてFPMSサーバ106と通信可能な点に注意する。

ERPサーバ128またはSCMサーバのような一つ以上のレガシー・タイプ・システムが、FPMSサーバ104と通信することができる。レガシー・タイプ・システムは、前から存在する在庫管理システムであって、会社でインストールされ、稼働している。各々のレガシー・タイプ・システムは、それぞれのレガシー・タイプ・システムのオペレーティングシステム、データフォーマット、プロトコルに従って在庫データを集めて、格納して、処理する。レガシー・タイプ・システムには異なるオペレーティングシステム、データフォーマット、および非互換のプロトコルがありうるので、システム100は統合サーバ130を利用してレガシー・タイプ・システムに既に格納され、処理されたデータを処理する。システム100は、エンタープライズ・アプリケーション・インテグレーション-タイプ（EAI）技術を使用している既存のERPシステムと融和するのに適している。

たとえば、FPMSサーバ106は、統合サーバ130と通信する。統合サーバ130は、レガシー・タイプ・システムから以前に格納されたデータとFPMSアプリケーション・プログラム104によって使われるデータを統合するのに適しているプロセッサに基づくプラットホームである。統合サーバ130は、プロセッサ132と、メモリ136に記憶される統合アプリケーション・プログラム134を含む。統合アプリケーション・プログラム134は、FPMSアプリケーション・プログラム104によって取り扱われるデータ入力とレガシー・タイプ・システムからのデータ入力を統合するための一組のコンピュータ実行可能な命令である。統合サーバ130は、ネットワーク102、直接的な接続性、無線通信、インターネットまたは他の通信-タイプ・ネットワークのいずれかを介してERPサーバ128と通信する。統合サーバ130は、ERPサーバ128のようなレガシー・タイプ・システムから受け取られるデータ入力を前処理する。ERPサーバ128のようなレガシー・タイプ・システムによって以前に格納されたデータ入力は、FPMSアプリケーション・プログラム112によってそれから処理されることができる。

一般に、ERPサーバ128は、プロセッサ138と、メモリ142に記憶されるERPアプリケーション・プログラム140を含むことができる。データ入力は、メモリ142内にまたはERPリレーショナル・データベース144内に記憶されることができる。ERPアプリケーション・プログラム140は、レガシー・タイプ・システムからデータ入力を受け取って、処理するための一組のコンピュータ実行可能な命令である。他の構成要素が、ERPサーバの範囲内でまたはERPサーバとともに存在するかもしれない。これらはSCMシステム、生産実行システム（MES）、製品ライフサイクル管理（PLM）システム、顧客関係管理（CRM）システムまたはこれらのシステムの一つ以上をインプリメントしている装置またはサーバを含むが、それらに制限されない。いくつかの例では、レガシー・タイプ・システムは、製造施設または会社でまだ運転中かもしれない。たとえば、関連入力装置148を介してERPクライアント146で以前入れられたデータ入力は、メモリ142またはリレーショナル・データベース144で記憶するためにERPサーバ128に送られうる。ERPアプリケーション・プログラム140は、レガシー・タイプ方法、データフォーマット、プロトコルに従ってデータ入力を処理するかもしれない。統合サーバ130は、ネットワーク102を介してまたは直接的な接続性によってERPサーバ128、メモリ142またはリレーショナル・データベース144からのデータ入力を検索するか、さもなければアクセスする。統合アプリケーション・プログラム134によって処理されるレガシー・データは、それからFPMSアプリケーション・プログラム104によって取り扱われうる。当業者は、本発明のいろいろな実施例に従ってレガシー・データをシステム100と統合するために必要ないろいろな方法および装置を見分けられるであろう。

ERPサーバ128および／またはネットワーク102は、少なくとも1つのあらかじめ定義されたフローパス148と通信している。フローパス148は、一つ以上のワークステーション（例えばオペレーション150a-nやステーション152a-n）を含む。先に述べたように、一つ以上のフローパスは、サプライチェーンの中に存在することができる。各フローパスは、ワークステーション（たとえば、製品、アイテムまたは商品が流れることができるか、さもなければ経由することができるオペレーション150a-nやステーション152a-nなど）を含む。在庫データ、パフォーマンス・データ、ルーティング・データまたは他のデータ入力は、オペレーション150a-nとステーション152a-nによって決定されるか、さもなければそれらから受け取られることができて、ERPサーバ128やネットワーク102を介してFPMSアプリケーション・プログラム112に送信されることができる。いくつかの場合では、そのようなデータはフローパス148からFPMSアプリケーション・プログラム112に直接送られることができ、さもなければフローパス148から直接受け取られることができる。当業者は、そのようなデータを送受信するために利用される方法と装置を分かるであろう。

前記以外のコンポーネントは、本発明のいろいろな実施例によればFPMSサーバ104およびFPMSアプリケーション・プログラム112と通信し、連携して動作してもよい。当業者はまた、本発明のいろいろな実施例に従うシステムと方法がハードウェア、ソフトウェアやそれらの組合せに実行されうることを分かるであろうことに注意する。

図2は、本発明のいろいろな実施例に従う、典型的なシステムのための典型的な計画階層の概略図を例示する。方法200は、図1で示されるシステム100によって実現される。更なる例として、方法200は本発明のいろいろな実施例によればERPアプリケーション・プログラム140とともに動いているフローパス管理システム（FPMS）アプリケーション・プログラム112によって実現される。方法200は、戦略、戦術、制御の少なくとも3つの機能的な層によって特徴づけられる。より少ないまたはより多い数の機能層が提供可能であり、そして、異なる機能層が同様に提供されてもよい。全体として、戦略、戦術および制御の機能は、サプライチェーンにおいてフローパスを管理する方法を表す。方法200のブロック202-210は戦略-タイプ機能を表し、ブロック212-228は戦術-タイプ機能を表し、ブロック230は制御タイプ機能を表す。

方法200はブロック202から始まり、そこでフローパスが決定される。フローパス管理システム（FPMS）アプリケーション・プログラム112は、サプライチェーンの中で少なくとも1つのアイテムのためのフローパスを定める。当業者は、フローパスを定めるために必要な方法と装置を認識するだろう。

ブロック202の後にブロック204が続き、そこでキャパシティ・リソース・プランニング(Capacity Resource Planning)は実行される。FPMSアプリケーション・プログラム112は、LWEモジュール内でワーク・センター利用度を示すことによって、キャパシティ・リソース・プランニングを実行する。

ブロック204の後にブロック206が続き、そこで集積された生産計画は実行される。FPMSアプリケーション・プログラム112は、LWEモジュールの範囲内で製品需要とワーク・センター利用度を示すことによって、集積された生産計画を実行する。

また、ブロック206に至って、ブロック208は集積された生産計画に対して需要予測を提供する。FPMSアプリケーション・プログラム112は、需要予測を決定する。

ブロック206の後にブロック210が続き、そこで在庫アドバイザー・モジュールは実行する。FPMSアプリケーション・プログラム112は、在庫アドバイザー・モジュールを実行する。在庫アドバイザー・モジュール210は、図3-6に関して以下により詳細に記述される。

また、ブロック210に至って、ブロック212は在庫アドバイザー・モジュールにベンダー・データを提供する。FPMSアプリケーション・プログラム112は、在庫アドバイザー・モジュールにベンダー・データを提供する。

ブロック212の後にブロック214が続き、そこでリオーダ・ポリシーがセットされる。図3-6に関して後で更に詳しく記述されるように、FPMSアプリケーション・プログラム112は在庫アドバイザー・モジュール（それはリオーダ・ポリシーをセットする）を実行する。

ブロック206を引用して、ブロック206の後にまたブロック216が続き、そこでロット・サイズとWIPエスティメータ（LWE）モジュールが実行する。FPMSアプリケーション・プログラム112は、ロット・サイズおよびWIPエスティメータ（LWE）モジュール216を実行する。ロット・サイズとWIPエスティメータ（LWE）モジュール216は、図7-9に関して後でより詳細に記述される。

また、ブロック216に至って、ブロック218はルーティング・データを提供する。図7-9に関して後で更に詳しく記述されるように、FPMSアプリケーション・プログラム112はルーティング・データを決定して、ロット・サイズとWIPエスティメータ（LWE）モジュール216にデータを提供する。

さらに、また、ブロック216に至って、ブロック220は材料表を提供する。FIGs.7-9に関して後で更に詳しく記述されるように、FPMSアプリケーション・プログラム112はロット・サイズとWIPエスティメータ（LWE）モジュール216に材料表を提供する。

ブロック214の後にブロック222が続き、そこで約束日ファインダー・モジュール（PDF）が実行する。FPMSアプリケーション・プログラム112は、約束日ファインダー・モジュール（PDF）222を実行する。約束日ファインダー（PDF）モジュール222は、図12に関して後でより詳細に記述される。

また、ブロック222に至って、ブロック224は在庫状況を提供する。図12に関して後でより詳細に記述されるように、FPMSアプリケーション・プログラム112は約束日ファインダー（PDF）モジュール222に在庫状況を提供する。

ブロック224の後にブロック226が続き、そこでCONWIPリリースが実現される。FPMSアプリケーション・プログラム112は、CONWIPリリースを実現する。

ブロック226の後に、ブロック222と230が続く。ブロック222では、方法200が在庫状況に戻り、ブロック222が続き、そこで約束日ファインダー・モジュールが実行し、そして、方法200は続く。ブロック230では、ジョブディスパッチングが実行され、そして、方法200は終わる。FPMSアプリケーション・プログラム112は、ジョブディスパッチングを決定する。

図2に示される特定のモジュールを参照すると、FPMSアプリケーション・プログラム112と関連する1つのモジュールは、在庫アドバイザー・モジュール210である。ブロック206に示される集積された生産計画および他のソースからのデータ入力に基づいて、在庫アドバイザー・モジュール210がストッキング・ポリシー、リオーダ・ポイントとリオーダ量を決定し、セットする。在庫アドバイザー・モジュール210も、需要とコストに基づいて、どの商品またはアイテムが「見込生産」であるべきか、そして、どの商品またはアイテムが「受注生産」であるべきか決定する。もし特定の商品またはアイテムについて「見込生産」されるべきという決定がなされたならば、在庫アドバイザー・モジュール210はその特定の商品またはアイテムのためにリオーダ・ポイントとリオーダ量を決定する。会社が原料または完成した商品をベンダーから購入しているときなど、リード・タイムが固定された環境下で、在庫アドバイザー・モジュール210は実行されうる。

在庫アドバイザー・モジュール210も、ユーザに特定の指標（例えばサイクルストック在庫コストに対する年間オーダー数、および安全ストック在庫に対するカスタマー・サービス・レート）の「効果的なフロンティア」の一つ以上のグラフィック・プロットを提供する。在庫と他の性能指標に基づいて、在庫アドバイザー・モジュール210は、少なくとも1本のイクスチェンジ・カーブを決定して、示す。ユーザは、それから、商品またはアイテムのために在庫を管理するか、ストッキング・ポリシーをセットするために、イクスチェンジ・カーブに沿ってまたは隣接してポイントを選ぶことができる。イクスチェンジ・カーブの例は、図3に300として示される。

図3に示される横ｘ軸302は、特定の商品またはアイテムについての１年当たりのオーダー数を表す。左側垂直ｙ軸304は、特定の商品またはアイテムについてのサイクルストックのドル価値を表す。第１のグラフィック・プロット306または「イクスチェンジ・カーブ」は、特定の年間オーダー数に対するサイクルストックのドル価値を表す。第2のグラフィック・プロット308は、現在のシステムが作動するところの性能指標を表す。2つのプロット306、308を使用して、プランナーのようなユーザは、互いに対してプロットされる一つ以上の「最適である」か「効率的な」性能指標を表しているイクスチェンジ・カーブに対して現在の在庫システムのパフォーマンスを比較することができる。図3に示される特定の例では、現在の在庫システム効率のグラフィック・プロット308は、最適のイクスチェンジ・カーブまたは「効果的なフロンティア」についてのグラフィック・プロット306よりわずかに上に示される。イクスチェンジ・カーブからの偏差の相対的な量は、現在の在庫システム効率と最適のまたは最大効率の指標との違いを示す。他の実用的な考慮（例えば最小限のオーダー量）は会社が最大効率を達成するのを妨げるかもしれないけれども、グラフィック・プロット306、308の間の比較は、在庫決定の改善の可能性があることを示し、そして、動作するイクスチェンジ・カーブに沿ってまたは隣接してユーザはポイントを選ぶことができる。

在庫アドバイザー・モジュール210は、１組のイクスチェンジ・カーブを構築し、ユーザに提供して、それから、リレーショナル・データベース106のようなデータベースに取り入れられる発見的方法を利用する。しばしば、以前に格納された発見的方法は、すでに関連ERPサーバ128またはシステムの中に存在する。

以下の方程式1.1−1.3はERPサーバ128またはシステムによって利用される発見的方法を表し、一例として提供される。他の方程式またはアルゴリズムが、本発明のいろいろな実施例で使われてもよい。この例では、需要Diおよび単位原価c_iを持つ製品iのための「経済的なオーダー量」（EOQ）は、次のように決定されうる：

アルファまたはAが「オーダー・コスト」であり、hは「在庫維持コスト比率」である。「オーダー・コスト」の値、アルファまたはAを推定することは、しばしば難しい。しかし、「２Ａ/h」の比率を変えることによって、306に類似したイクスチェンジ・カーブは、「オーダー・コスト」、アルファまたはAのためにこれまでに値を特定しまたは計算することなく、総サイクルストック・コストと年間オーダー数を比較するために決定されることができる。

トータル・アヴェレージ・サイクルストック在庫コストは、以下のように決定されうる：

一年のオーダーの平均数は、以下のように決定されうる：

一旦イクスチェンジ・カーブが決定されたら、次にイクスチェンジ・カーブを見ているユーザはどこでイクスチェンジ・カーブに沿ってまたは隣接していたいかについて決める。対応するユーザ入力は入力装置126またはウェブサイト118を通して受け取られ、そして、ユーザの入力または決定は商品またはアイテムの在庫に関して実行されうる。

同様に、「ペナルティ・コスト」パラメータ、ベータまたはbは、計算または決定することがしばしば難しい。しかしながら、安全在庫への総投資に対する年間の予想される品切れ総数を示し、図3に示される306に類似する、イクスチェンジ・カーブは、「ペナルティ・コスト」、ベータまたはbの値を特定する代わりに、決定されうる。一旦イクスチェンジ・カーブが決定されると、イクスチェンジ・カーブを見たユーザは、それからイクスチェンジ・カーブに沿ってまたは隣接してユーザが望む場所を決定する。対応しているユーザ入力は入力装置126またはウェブサイト118を通して受け取られることができ、ユーザの入力または決定は商品またはアイテムの在庫に関して実行されうる。

このように、在庫アドバイザー・モジュール210は、現在のパフォーマンス・データ・メジャー（例えば年毎のオーダー数、フィル・レートと在庫投資）を報告して、それからこれらのパフォーマンス・データ・メジャーのうちの少なくとも2つに制約をセットして、それから第3のパフォーマンス・データ・メジャーを最適化する。在庫アドバイザー・モジュール210がフローパスで複数のアイテムを取り扱うために実行される点に注意し、そして、各々のアイテム間で在庫とサービスをトレードオフすることによって、システム100により改善された在庫決定がなされ、処理されうる。

他の例では、所定の年間注文数w_oを上回らず、一方、総在庫投資を最小にしつつ、カスタマーは要求フィル・レートSoを満たすか上回ることを望むと仮定する。この例は、在庫アドバイザー・モジュール202が対応するイクスチェンジ・カーブを処理して、決定するための複数の変数を含む。リード・タイム需要（D）の平均と分散は仮の合成需要プロセス、

とYのために決定される。ここで、

はある期間のオーダー数を表す確率変数であり、Yはオーダーのサイズである。

の平均はλで、分散は

である。同様に、

リード・タイムは一定で、

に等しい。以下の方程式が使われる：

もしリード・タイムがランダムで、

ならば、以下の方程式が使われる：

上記の方程式2.2はそれから、正規分布の平均と分散を決定するのに用いられ、そして、それはそれから合成ポアソンの近似値を求める。アイテムiのコストとしてCiおよびiで指標付けられた他のパラメータを用いるZipkin表記法を使用して、在庫を最小にする複数の可変的な問題は、以下のように記述できる：

オーダー総数がw₀に限られていることを前提として

そして、フィル・レートは少なくともS₀と同然のリオーダ量とリオーダ点の関数である。

リオーダ量とリオーダ点は、次の式から計算される：

上記の例に対してイクスチェンジ・カーブを決定するために、変数Aは第１の制約に合うために最適化され、変数bは第2の制約に合うために最適化される。コンセプトは、「セットアップ・コスト」パラメータAと「ペナルティ・コスト」パラメータbを「ターン」と「フィル・レート」のより実際的なパラメータに合わせることである。この種の発見的手法は、最適在庫ポリシーのおよそ5%以内に、通常、値を決定する。

別の例では、1年につき8つのターンとおよそ99.9%のフィル・レートを目標としている会社に在庫アドバイザー・モジュール202で推薦される「最適ものに近い」在庫ポリシーは、一般の在庫ポリシーより年につきわずかに少ないオーダーでのおよそ75%小さな在庫投資とわずかに良いフィル・レートを持った。

方程式1.1-1.3と2.1-2.5が例として提供される点に注意する。イクスチェンジ・カーブは、他の方程式、上記の方程式の組合せまたは上で提供された方程式の変数を使って決定または、生成されうる。上記の例は、イクスチェンジ・カーブを決定するために本発明で使われる開示された方法を限定することを意図しない。

図4Aを参照して、本発明のいろいろな実施例に従う典型的な方法400を示す。方法400は、サプライチェーンにおいて類似したアイテムについての在庫を管理し、ストッキング・ポリシーを設定するのに適している。示される実施例において、方法400は図1で100として示されるシステム実施例によって実行されうる。一例として、参照は図1に示されるシステム100の要素になされるだろう。

方法400は、ブロック402から始まる。

ブロック402の後にブロック404が続く、サプライチェーンにおけるアイテムのためのフローパスが決定される。在庫アドバイザー・モジュール210は、アイテムのためにフローパスを決定する。フローパスは少なくとも1つのオペレーションを含んで、ほとんどの場合に複数のオペレーションを含む。サプライチェーンでフローパスを決定するための従来のシステムと方法は、実行されうる。

ブロック404の後にブロック406が続く。そこにおいて、各々のオペレーションでアイテムのための在庫データが受け取られる。在庫アドバイザー・モジュール210は、ネットワーク102、ERPサーバ128、ERP アプリケーション・プログラム140またはデータベース106、144を介してフローパスの中でアイテムと関連する在庫データを受け取る。在庫データは、データ入力、選択データ、期間当たりのオーダー、サイクルストック・コスト、変動と平均単位原価、フローパス割当て、サイクルのスループットの計量単位、リード・タイムおよび最小と最大のロット・サイズを含むが、これらに限定されるものではない。

ブロック406の後にブロック408が続く。そこにおいて、在庫データは記憶される。在庫アドバイザー・モジュール210は、以降の処理のために受け取られた在庫データをメモリ114またはリレーショナル・データベース106に保存する。他のメモリまたはデータ記憶タイプ装置が、本発明のいろいろな実施例に従って使用可能である。

ブロック408の後にブロック410が続く。そこにおいて、アイテムのための需要要因は決定される。在庫アドバイザー・モジュール210は、アイテムと関連する需要要因を決定する。在庫データの一部または全部を利用して、在庫アドバイザー・モジュール210は、需要要因を決定するために上記の方程式2.1および2.2で例示されるような一つ以上のアルゴリズムを適用する。需要要因は、事前に決められた期間にわたるアイテムに対するいくつかのオーダー、リオーダ・リード・タイムの間の期待される需要および確率変数としての需要の分布を含むが、これに限定されるものではない。

ブロック410の後にブロック412が続く。そこにおいて、アイテムに対するコスト要因は決定される。在庫アドバイザー・モジュール210は、アイテムと関連するコスト要因を決定する。在庫データの一部または全部を利用して、在庫アドバイザー・モジュール210は、コスト要因を決定するために上記の方程式2.1および2.2で例示されるような一つ以上のアルゴリズムを適用する。コスト要因は、アイテムに対する総サイクルストック・コスト、アイテムに対する総安全在庫コストまたはこれらの2つの値に加えて他のコスト・ドライブ（例えば輸送、保管および不足在庫費）の加重平均を含むが、これに限定されるものではない。

ブロック412の後にブロック414が続く。そこにおいて、需要要因およびコスト要因に部分的に基づいて、アイテムのためのイクスチェンジ・カーブは決定される。在庫アドバイザー・モジュール210は、ブロック408で決定される需要要因とブロック410で決定されるコスト要因に部分的に基づいてイクスチェンジ・カーブを決定する。イクスチェンジ・カーブは、需要要因およびコスト要因と関連する在庫データを例示するために生成され、または決定されうる。

ブロック414の後にブロック416が続く。そこにおいて、イクスチェンジ・カーブとアイテムに対する在庫データの一部が示される。一旦イクスチェンジ・カーブが決定されると、在庫アドバイザー・モジュール210は、クライアント116と関連する表示装置（図示せず）でユーザが見るために、ウェブサイト118にイクスチェンジ・カーブを示すことができる。

ブロック416の後にブロック418が続く。そこにおいて、方法400は終わる。

方法400がイクスチェンジ・カーブを示したあと、もう一つの方法420がイクスチェンジ・カーブを利用するために実行されてもよい。図4Bは、方法420を例示する。

ブロック422で、方法420は始まる。ブロック422の後にブロック424が続く。そこにおいて、サプライチェーンの中のアイテムに関する少なくとも1つの在庫決定が示される。在庫アドバイザー・モジュール210がイクスチェンジ・カーブを示したあと、ユーザはイクスチェンジ・カーブに沿ってまたは隣接していろいろなポイントを選んでもよい。各々のポイントは、システム100が動作することができるいろいろな性能指標と関連する動作点を表す。クライアント116で入力装置126を使って、ユーザはイクスチェンジ・カーブに沿ったまたは隣接したポイントをハイライトさせまたは選ぶことができる。ユーザが特定のポイントをハイライトしまたは選ぶとき、イクスチェンジ・カーブに沿ったまたは隣接した特定のポイントと関連する性能値が示される。特定のポイントと関連する性能値は、ユーザが選ぶことができる潜在的な在庫決定を表す。在庫決定は、アイテムの受注生産とアイテムの見込生産を含むが、これらに限定されるものではない。

ブロック424の後にブロック426が続く。そこにおいて、在庫決定に対応するユーザ入力が受け取られる。もしユーザがイクスチェンジ・カーブに沿うまたは隣接する特定のポイントを決定したら、ユーザは入力装置126にてデータ入力を送ることによってポイントを選ぶ。クライアント116は、イクスチェンジ・カーブに沿うまたは隣接するポイントに関して在庫決定に対応する関連情報を送信する。

ブロック426の後にブロック428が続く。そこにおいて、 在庫決定に従って、オペレーションでアイテムに関して在庫決定が実行される。ウェブサイト118はクライアント116からデータ入力を受け取って、データ入力をFPMSアプリケーション・プログラム112に送る。FPMSアプリケーション・プログラム112は、ユーザによって選ばれる在庫決定と対応するサプライチェーンに沿ってまたはフローパスにおいて命令をオペレーションに送る。

ブロック428の後にブロック430が続く。そこにおいて、方法420は終わる。

方法400がイクスチェンジ・カーブを示したあと、もう一つの方法432が実行されてもよい。図4Cは、方法432を例示する。

ブロック434で、方法432は始まる。ブロック434の後にブロック436が続く。そこにおいて、事前に決められた期間にわたって予想される品切れ数および安全在庫についての投資が決定される。在庫アドバイザー・モジュール210がイクスチェンジ・カーブを示したあと、ユーザは事前に決められた期間にわたって安全在庫および予想される品切れ数を示している性能データを見ることを選んでもよい。在庫アドバイザー・モジュール210は、この性能データに対応しているさらなるカーブを決定する。

ブロック436の後にブロック438が続く。そこでは、事前に決められた期間につき安全在庫および予想される品切れ数への投資に基づいて、ペナルティ・コスト曲線が決定される。在庫アドバイザー・モジュール210は、この性能データに対応している新たなカーブを決定する。例えば、ベータまたはbに関する上記の式は、ペナルティ・コスト曲線を決定するのに用いることができる。

ブロック438の後にブロック440が続く。そこにおいて、ペナルティ・コスト曲線とアイテムに対する在庫データの一部が示される。一旦ペナルティ・コスト曲線が決定されると、在庫アドバイザー・モジュール210はクライアント116と関連する表示装置（図示せず）でユーザが見るためにウェブサイト118でペナルティ・コスト曲線を示すことができる。

ブロック440の後にブロック442が続く。そこにおいて、方法432は終わる。

方法400、420および432がフローパスまたはサプライチェーンの中でいくつかまたは全てのアイテムのために実行されうる点に注意する。図4Aの方法400はサプライチェーンの中で複数種類のアイテムのために実行されうる。ここで、異なるタイプのアイテムがサプライチェーンの中で取り扱われてもよくまたさもなければ処理されてもよい。そのような場合、他のタイプのアイテムに対するそれぞれの在庫データを受け、それぞれの在庫データを記憶し、それぞれの在庫データに対する需要要因およびコスト要因を決定し、それぞれのイクスチェンジ・カーブを決定し、そして、他のタイプのアイテムに対するそれぞれのイクスチェンジ・カーブとそれぞれの在庫データの一部を示すための新たな機能ブロックが、実行されうる。同様に、方法420および432は、必要に応じてそれぞれのタイプのアイテムに関して、実行されうる。

図5は、本発明のいろいろな実施例による方法およびシステムに対する典型的なユーザインタフェースのスクリーン・ショットの上部である。スクリーン・ショットの上部は、フロー・ポイント・マネジメント・システム（FPMS）アプリケーション・プログラム112と関連する在庫アドバイザー・モジュール210のための、ユーザインタフェース500を例示する。在庫アドバイザー・モジュール210は、ユーザインタフェース500を提供する。ユーザインタフェース500は、選択データのようなユーザ入力を受け取るために一連の選択装置502-510を含む。各々の選択装置502-510は、選択データ（例えばフローパス502、最適化方法504、オーダーの最小数506、オーダーの最大数508およびプロット在庫関係ボタン510）を受け取る。例えば、ユーザインタフェース500はネットワーク102と通信してウェブサーバ108によってホストされているウェブサイト118上で、在庫アドバイザー・モジュール210によって示されうる。ユーザ・オペレーティング・クライアント116は、ブラウザー・アプリケーション・プログラム124によってユーザインタフェース500にアクセスすることができる。入力装置126によるユーザ入力は、選択装置502-510で受け取られる。例えば、示される例では、ユーザはフローパスに対応している選択デバイス502に対して「全て」を選択し、最適化方法に対応している選択デバイス504に対して「ユニット・フィル・レートを最適化する(Optimize Unit Fill Rate)」を選択し、オーダーの最小数に対応している選択デバイス506へ数値「5」を入力し、そしてオーダーの最大数に対応している選択デバイス508へ数値「198」を入力した。他の選択、数または量が、エンター又はインプットされうる。選択デバイスは、プル・ダウン・メニュー、テキスト・フィールド、ボタン、ラジオ・ボタンまたは他の類似したデバイスを含むが、これらに限定されない。本発明の実施例によれば、さまざまなタイプの選択データを集める他の選択デバイスが利用されうる点に注意する。

ユーザインタフェース500も、一つ以上のイクスチェンジ・カーブ512、514を含む。在庫アドバイザー・モジュール210は、モジュール210で受け取られる在庫データに、部分的に基づいて、そしていくつかの例では選択デバイス502-510を通して受け取られるデータ選択データに基づいて、イクスチェンジ・カーブを決定する。イクスチェンジ・カーブ512、514が在庫データおよび／または選択データの特定の組合せに対して決定されるとき、在庫アドバイザー・モジュール210は選択デバイス502-510に隣接するスクリーン・インターフェースにイクスチェンジ・カーブ512、514を示す。

この例では、選択データは、選択デバイス502を通して全てのフローパスに関して受け取られることができる。フローパスと関連する選択データの任意選択は、特定の事前に決められたフローパスを選択すること、または全てのフローパスを選択することを含むことができるが、それらに限定されない。選択データは、また、選択デバイス504を通して最適化方法に関して受け取られることができる。最適化方法と関連する選択データのオプションは、ユニット・フィル・レートの最適化、ドル・フィル・レートの最適化、品切れ数の最少化、そして全アイテムのサービス・レベルの均一化を含むことができるが、それらに限定されない。これらの最適化方法は、図7に関してさらに記述される。他の選択データは、オーダーの最小数に関して受け取られることができる。オーダーの最小数と関連する選択データのためのオプションは、事前に決められたオーダー数を含むことができるが、それに限定されない。他の選択データは、選択デバイス506を経てオーダーの最小数に関して受け取られてもよい。オーダーの最小数と関連する選択データのためのオプションは、事前に決められたオーダー数を含んでもよいが、それに限定されない。他の選択データは、選択デバイス508を経てオーダーの最大数に関して受け取られてもよい。オーダーの最大数と関連する選択データのためのオプションは、事前に決められたオーダー数を含んでもよいが、それに限定されない。選択デバイス510を通して、イクスチェンジ・カーブのような在庫関係をプロットまたはグラフで示したいというユーザの要求と関連する選択データが、入れられうる。この例では、ユーザは、選択デバイス502-508のどんな組合せによって新しい選択データを入力してもよく、そしてそれから、新しい選択データに基づく選択デバイス510を経て、最新イクスチェンジ・カーブを要請してもよい。在庫アドバイザー・モジュール210は、新しい選択データを受け取り、そして新しい選択データに部分的に基づく一つ以上のイクスチェンジ・カーブ512、514を更新する。

この例で示されるイクスチェンジ・カーブ512, 514は、サイクルストック対時間あたりオーダーおよび安全在庫対加重オーダー完成確率をそれぞれ例示する。第１のイクスチェンジ・カーブ512は、横x軸516に沿った時間あたりのオーダー数および縦y軸518に沿ったサイクルストック値を含む。イクスチェンジ・カーブ512は、在庫データと選択データの特定のセットに対して、軸516、518の各々に関してプロットされる。図6に示され、かつ記述されているように、ユーザはイクスチェンジ・カーブ512に沿ってまたは隣接して特定のポイントを選び、そしてイクスチェンジ・カーブ512に基づいて在庫を決定してもよい。同様に、第2のイクスチェンジ・カーブ514は、横x軸520に沿った加重オーダー完成確率および縦y軸522に沿った安全在庫値を含む。イクスチェンジ・カーブ514は、在庫データと選択データの特定のセットに対して、軸520、522の各々に関してプロットされる。図6に示され、かつ記述されているように、ユーザはイクスチェンジ・カーブ514に沿ったまたは隣接した特定のポイントを選び、イクスチェンジ・カーブ514に基づく在庫決定をしてもよい。他のタイプのイクスチェンジ・カーブが、在庫データおよび／または選択データに基づいて在庫アドバイザー・モジュール210によってプロットおよび表示されてもよい点に注意する。

図6は、図5で示されるスクリーン・ショットの下部である。スクリーン・ショットの下部は、フロー・ポイント・マネジメント・システム（FPMS）アプリケーション・プログラム112と関連する在庫アドバイザー・モジュール210のユーザインタフェース600を例示する。在庫アドバイザー・モジュール210は、ユーザインタフェース600を提供する。ユーザインタフェース600は、在庫データを示すための一連の表示デバイス602-620と、選択データなどのユーザ入力を受け取るための選択デバイス622を含む。図5に示されるユーザインタフェース500のイクスチェンジ・カーブ512、514の下部も、このスクリーン・ショットの中で見られてもよい。各々の表示デバイス602-620は、アルファ値602のような在庫アドバイザー・モジュール210の表示データ、予想されるサイクルストック604、予想されるオーダー数606、ベータ値608、予想される安全在庫610、加重オーダー完成確率612、部品番号614、部品またはアイテム616の説明、リオーダ・ポイント618およびリオーダ量620を受け取る。示される選択デバイス622は、データ保存ボタンである。

ユーザインタフェース500と類似の、ユーザインタフェース600はまた、ウェブサイト118で在庫アドバイザー・モジュール210によって表示され、入力装置126を操作しているユーザから選択データを受け取ってもよい。

この例では、表示データは、表示デバイス602によってアルファ値に関して示されてもよい。図2の例で説明されたように、アルファ値またはAは、在庫データおよび／または選択データによって定義される第１の制約に合うように在庫アドバイザー・モジュール210によって最適化される。表示データは、また、表示デバイス604による予想されるサイクルストックに関して在庫アドバイザー・モジュール210によって決定されてもよい。予想されるサイクルストックの値は、在庫データおよび／または選択データを使用して在庫アドバイザー・モジュール210によって決定されてもよい。他の表示データは、表示デバイス606による予想されるオーダー数に関して、在庫アドバイザー・モジュール210によって決定されてもよい。予想されるオーダー数の値は、在庫データおよび／または選択データによって定義されてもよい。表示データは、表示デバイス608によるベータ値に関して示されてもよい。図2の例で説明されたように、ベータ値またはbは、在庫データおよび／または選択データによって定義される第2の制約に合うように在庫アドバイザー・モジュール210によって最適化される。表示データは、また、表示デバイス610による予想される安全在庫に関して在庫アドバイザー・モジュール210によって決定されてもよい。予想される安全在庫の値は、在庫データおよび／または選択データを使用して在庫アドバイザー・モジュール210によって決定されてもよい。他の表示データは、表示デバイス612による加重オーダー完成確率に関して在庫アドバイザー・モジュール210によって決定されてもよい。加重オーダー完成確率の値は、在庫データおよび／または選択データを用いて在庫アドバイザー・モジュール210によって決定されてもよい。

関連する表示データは、表示デバイス614-620によって示されてもよい。表示デバイス614に、部品番号が在庫アドバイザー・モジュール210によって示される。表示デバイス616に在庫アドバイザー・モジュール210によって表示される部品またはアイテムの説明は、部品番号と関連する。各々の部品番号と関連部品説明に対して、在庫アドバイザー・モジュール210は、在庫データおよび／またはユーザ選択データに部分的に基づくリオーダ点とリオーダ量を決定する。リオーダ点とリオーダ量は、それぞれ表示デバイス618と620に示される。

選択デバイス622によって、ユーザは在庫関係と関連する表示されたデータ（例えばイクスチェンジ・カーブ、リオーダ点またはリオーダ量）の一部または全部を保存してもよい。この例では、ユーザは選択デバイス622への入力を入力することによってデータを記憶してもよい。そして、それは後の参考のために、表示されたデータの一部または全部を記憶する。在庫アドバイザー・モジュール210は、その後の使用または参照のために表示されたデータをリレーショナル・データベース106、メモリ114または他のメモリまたはデータストレージ・デバイスに記憶する。

このスクリーン・ショットに示されるイクスチェンジ・カーブ512、514の一部は、また、図5に示される。入力装置126を使用して、ユーザはイクスチェンジ・カーブ512、514の一方または両方に沿ってまたは隣接して特定のポイントを選び、イクスチェンジ・カーブ512、514の一方または両方に基づく在庫決定を選ぶことができる。例えば、入力装置126を使って、ユーザはイクスチェンジ・カーブ512に沿ってポイントをハイライトすることができ、ウインドウ（図示せず）は、x軸516とy軸518上の値に対応するx座標とy座標を表示することができる。イクスチェンジ・カーブ512の全体的な表示と、イクスチェンジ・カーブ512と関連する表示されたデータ（例えば、アルファ値602、予想されるサイクルストック604、予想されるオーダー数606など）を使用して、ユーザは在庫決定を入力してもよい。

図7は、本発明のいろいろな実施例による方法およびシステムの典型的なユーザインタフェースの他のスクリーン・ショットである。図5で先に述べたように、選択データは、また、選択デバイス504を経て最適化方法に関して受け取られてもよい。図7に示すように、ユーザインタフェース700は最適化方法（例えば、ユニット・フィル・レートの最適化702、ドル・フィル・レートの最適化704、品切れ数の最少化706、全アイテムのサービス・レベルの均一化708など）のためのいろいろなオプションを表示する。

一例として、ユニット・フィル・レートの最適化702などの最適化方法は、在庫から満たされる需要ユニットのパーセンテージを最大にするように安全在庫をセットする。異なるアイテムがそれらのロット・サイズ、需要レイトおよび需要変動に従って変化するだろうから、集積されたサービスを最適化することは、結果として品目別に異なるサービス・レベルとなってもよい。

更なる例として、ドル・フィル・レートの最適化704などの最適化方法は、在庫から満たされる需要の金銭ベースのパーセンテージを最大にするように安全在庫をセットする。異なるアイテムがそれらのユニット値、ロット・サイズ、需要レイトと需要変動によって変化するだろうから、集積されたサービスを最適化することは、結果として品目別に異なるサービス・レベルとなってもよい。

さらに、品切れ数の最少化706などの最適化方法は、どんなアイテムでも品切れするであろう補充サイクル数を最小にする安全在庫をセットする。我々は補充サイクルに目を向けているので、全ての停止は、アイテムの数やそれらの価格にかかわらず、等しく扱われる。異なるアイテムがそれらのロット・サイズ、需要レイトと需要変動によって変化するだろうから、集積されたサービスを最適化することは結果として異なるアイテムに対しては品切れ可能性が異なってもよい。

全アイテムのサービス・レベルの均一化708（別名、品切れ可能性の均一化）のような他の最適化方法は、補充サイクル当たりの一般的な品切れ確率（例えば、20サイクルにつき1。およそ全アイテムに対して95%のサービス）を設定する。我々が品切れサイクルに目を向けているので、全ての停止は、アイテムの数やそれらの価格にかかわらず、等しく扱われる、したがって、全てのアイテムに対して等しいサービスレベルとなる。あらゆるアイテムは同じ停止確率に従う。そして、それは停止の総数を最小にしないかもしれない。

本発明のいろいろな実施例に従う他の最適化方法が実行されてもよい点に注意する。

ユーザが選択デバイス504の上で入力装置を操作するとき、各々のオプションはハイライトされる。ユーザがオプションを選ぶと、ユーザの選んだオプションに対応する信号がウェブサイト118に送られて、それから処理のために在庫アドバイザー・モジュール210に送られる。

図2を参照すると、FPMSアプリケーション・プログラム112と関連する他のモジュールは、ロット・サイズと仕掛品（WIP）エスティメータ・モジュール216、つまり"LWE"モジュールである。このモジュール216は、フローパスでの時間を最小にするロット・サイズを決定しセットするのに適している。LWEモジュール216は、アイテムのスループット・レートが実行可能なとき、決定するのにさらに適している。つまり、1または複数のアイテムまたは製品に対する望ましいスループット・レートを与えられたとすると、LWEモジュール216はそのスループット・レートが実行可能かどうか決定し、もしそうならば、集約された製品にわたって、最適なサイクル・タイムに至るまで平均サイクル・タイムを最小にする個々のアイテムのためのロット・サイズを見つける。この最適な平均サイクルを与えられたとすると、LWEモジュール216は、それから、例えば、CONWIPまたはカンバン(Kanban)コントロール・スキームで使用するシステムに広がる仕掛品（WIP）レベルを実行する。

さらにまた、LWEモジュール216は、選ばれたルーティング・データのグラフィック・プロットを生成するのに適している。スループット・レートの複数のコレクションについて繰り返し使用されて、LWEモジュール216は、スループット・レート、WIPレベルと平均総サイクル・タイムの間のいろいろなトレードオフを表す、図8のようなグラフィック・プロットを生じる。

LWEモジュール216によって利用される見本アルゴリズムは、サプライチェーンにおいて1または複数のアイテムに関して適切なロット・サイズを決定するのに適している。後述するアルゴリズムは、必要に応じて反復的な方法で実行されてもよい。まず、初期設定ステージでは、ロット・サイズのベクトルは、戦略的な方法で初期化される。例えば、現在のロット・サイズを選ぶ。次に、見積と評価ステージでは、結果として生じるサイクルが見積もられて評価される。改善ステージでは、（総サイクル・タイムに対して）最も急な改善の指示が決定され、ロット・サイズの新しいベクトルが選ばれる。最適なロット・サイズが決定されるまで、これらのステップとステージのどんな組合せも必要に応じて繰り返されうる。

LWEモジュール216のデータ出力が少なくとも部分的に「クローズド」在庫システムのために、適合させられるが、LWEモジュール216は、ロット・サイズを見積もるとき、「クローズド」および「オープン」タイプ在庫システムとともに実行されうる。例えば、以下のアルゴリズムは、両方の種類の在庫システムのために利用されうる。個々のアイテムはi = 1,...,Nで示され、ステーションはj = 1,...,J、で示されると仮定する。この例では、在庫システムに対して少なくとも5種類のデータ入力がある：

各ステーションjに対して、「生産的な利用度」は次のように決定されうる：

量u_jは、タイムステーションjのロングラン・フラクションはビジー・プロセッシング・パーツであり、転換を実行することに費やされる時間から独立していなければならないということを表す。上記のアルゴリズムでは、所定のアイテムに対するロット・サイズは、全ステーションにわたり同じであるようにセットされる。

他のアルゴリズムでは、結果として生じるロット・サイズは、ステーションの全域で異なるかもしれない。最初のステーションのロット・サイズは、その後のステーションとで違って決定される。初期設定ステージでは、我々はロット・サイズを最初のステーションに対して以下の通り設定した：

はステーションjの平均待ち行列時間の下限、

はステーションjの製品iに対して結果として生じるロット・サイズである。上記のアルゴリズムはシングル・ステーション・システムへのアイテム到着がポアソンであり、そのアイテム到着はコントロール・タイプ・メカニズムによって命じられるサイズのバッチで来るというモデリング仮定を含む。

下流のステーションのために、いくつかの代替アルゴリズムも、使用されうる。1つの代替は各々のステーションで「プロダクション・ラン」を等しく設定することを含む。ここで、タイプ（i,j）プロダクション・ランはステーションjでアイテムiのロットの処理に費やされる総時間（セットアップは除外される）として定義される。

つまり、ステーションjとアイテムiとkは、

は、ステーションjで一般的なプロダクション・ランである。

変数

は、

の発見学習的に選ばれた目標「総利用度」を達成するためにセットされる：

かくして、ロット・サイズに対する解は、初期設定ステージを含み、そして次の式を得る：

次に、見積と評価ステージでは、各々のアイテムのためのサイクル・タイム見積は、ホップとスピアマンによって提案された調整済み変動係数とともに、Whittによって開発された待ち行列ネットワークアナライザー（QNA）-タイプ方程式のセットアップ-タイム調節を使用して決定される。メトリクはそれから、選ばれたロットサイズ・ベクトルQに対する潜在的な依存を強調するためにf(Q)と表示された総加重フローについて決定される。

改善ステージでは、有限要素解析または方法は、総量

のグラジエントを見積もるために使用される。ロットサイズ・ベクトルは、次の方程式によってアップデートされる：

Δは選ばれたステップ・サイズで、

の局所極小が決定されるまで、分析は反復的な方法で繰り返される。

一旦ロット・サイズのベクトルが決定されると、アイテムのためにWIPレベルを見積もることはリトル法を使用して簡単である。

上記のアルゴリズムが先の例で提供されるそれらと類似している点に注意する。上記のアルゴリズムでは、ステーションにかかわらず、各々のアイテムが一つのロット・サイズを持つという仮定がなされた。上記の初期設定ステージは、単一ステーションで方程式3.1を解くことを含む。一般的に、このステーションは最大の切り換えタイムをもつステーションであるが、他のステーションが選ばれるかもしれない。いずれにしても、このロット・サイズは、それからフローパスまたはサプライチェーン内のあらゆるステーションで使用される。改善ステージでは、同じロット・サイズが、ステーション全体で維持される。

LWEモジュール216によって実行される従来のアルゴリズムとアルゴリズムとの間のパフォーマンス比較は、上記のアルゴリズムの初期設定ステージから発見学習的に選ばれたロット・サイズを使用してなされうる。例えば、比較分析が5つのアイテムについて実行され、5つのステーション・システムの結果は、表1に示す以下のサイクル・タイムとなった：

表1で見られるように、LWEモジュール216によって決定される調整ロット・サイズによって達成される最適サイクル・タイムは従来の帰納的なスターティングソリューションを使用して達成されるサイクル・タイムよりおよそ35%少ない。パフォーマンスの違いは、最初のロット・サイズの改善された選択を通して、最適ロット・サイズへのより速い収束に関して、サイクル・タイムについてかなりの改善が得られることを示す。ステーションに特有のロット・サイズが選ばれるとき、最適解もまた、改善する点に注意する。

LWEモジュール216は、また、Kanban-タイプまたはCONWIP-タイプ在庫システムのいずれかで仕掛品（WIP）レベルを決定するために使用される。比較的速い「サンプルパス」シミュレーション・テクニックを使用して、LWEモジュール216は、スループット対WIPレベルおよび平均サイクル・タイム対平均WIPレベルのグラフィック・プロットを提供する。LWEモジュール216によって提供されるグラフィカル・プロットの例が、図8に800として示される。

図8において、横x軸802は、商品またはアイテムのバッチ量によって、WIPを表す。左サイドの縦y軸804は、数分のロットに関して、サイクル・タイムを表す。右サイドの縦y軸806は、期間あたりパーツでスループット量を表す。第１のグラフィカル・プロット808は、特定のWIP対サイクル・タイムを表す。第2のグラフィカル・プロット810は、特定の商品またはアイテム対サイクル・タイムに関してスループットを表す。各々のグラフィカル・プロットに対する最適または「最高の」結果は、それぞれグラフィカル・プロット812、814によって示される。所定のWIP量に対して、ユーザがサイクル・タイムを最小にしたいかもしれない点に注意する。2つのプロット808, 810を使用して、在庫プランナーのようなユーザは、サイクル・タイムを最小にすると同時に、需要に合うように在庫スループットの量を十分にセットするWIPレベルを決めることができる。図8に示される特定の例では、最適WIPレベルは、およそ八(8)バッチである。

図9Aを参照して、本発明のいろいろな実施例による他の典型的な方法900が示される。方法900は、サプライチェーンの中で類似したアイテムのロット・サイズを管理するのに適している。示される実施例では、方法900は、図1で100として示されるシステム実施例によって実行されうる。一例として、図1に示されるシステム100の要素が参照されるであろう。

方法900は、ブロック902から始まる。

ブロック902の後にブロック904が続く。そこにおいて、第１のオペレーションでのアイテムの初期ロット・サイズが決定される。ロット・サイズおよびWIPエスティメータ（LWE）モジュール216は、フローパスまたはサプライチェーンの中の第１のオペレーションでのアイテムの初期ロット・サイズを決定する。従来の方法およびデバイスは、初期ロット・サイズを決定するために使用されうる。

ブロック904の後にブロック906が続く。そこにおいて、各々のオペレーションのアイテムに関するルーティング・データが受け取られる。ロット・サイズおよびWIPエスティメータ（LWE）モジュール216は、ネットワーク102、ERPサーバ128、ERPアプリケーション・プログラム140またはデータベース106,144を経てフローパスの中でアイテムと関連するルーティング・データを受け取る。ルーティング・データは、性能指標、性能データ、データ入力、選択データ、ロット・サイズ、フロータイム、フローパスの遅れ時間、セットアップ・タイム、セットアップ・タイムの変動、プロセス・タイム、プロセス・タイムの変動および収率損失を含むが、これに限定されるものではない。

ブロック906の後にブロック908が続く。そこにおいて、ルーティング・データが記憶される。LWEモジュール216は、その後の処理のために受け取られた在庫データをメモリ114またはリレーショナル・データベース106に記憶する。他のメモリまたはデータ記憶タイプ・デバイスは、本発明のいろいろな実施例に従って使用されうる。

ブロック908の後にブロック910が続く。そこにおいて、サプライチェーン中を第１のステーションから流れているアイテムに関するサイクル・タイムが、ルーティング・データに基づいて、決定される。LWEモジュール216は第１のステーションから流れているアイテムに関するサイクル・タイムを、以前に記憶されたまたは受け取られたルーティング・データに基づいて、決定する。例えば、サイクル・タイムは、オペレーションの始まりから全オペレーションの完成に至るまでのフローパス内での特定のアイテムについての経過時間量を含むことができるが、これに限定されるものではない。

ブロック910の後にブロック912が続く。そこにおいて、サプライチェーン中を第１のステーションから流れているアイテムに関するサイクル・タイムに少なくとも基づいて、そのアイテムに関する望ましいフロータイムが決定される。LWEモジュール216は、フローパスの中でのアイテムの望ましいサイクル・タイムを決定する。一例として、LWEモジュール216は、選ばれたサイクル・タイムを決定するために、上記のアルゴリズム3.1-3.5を利用することができる。

ブロック912の後にブロック914が続く。そこにおいて、アイテムのために選ばれた望ましいサイクル・タイムに少なくとも基づいて、第１のオペレーションのアイテムのための初期ロット・サイズが調整される。一旦LWEモジュール216が望ましいサイクル・タイムを受け取るか決定すると、アイテムのための初期ロット・サイズは必要に応じて調整される。

ブロック914の後にブロック916が続く。そこにおいて、方法900は終わる。

方法900がブロック916で初期ロットを調節したあと、他の方法918が望ましいサイクル・タイムを利用するために実行されうる。図9Bは、方法918を例示する。

ブロック920で、方法918は始まる。ブロック920の後にブロック922が続く。そこにおいて、サプライチェーンの第１のタイプのアイテムに関する少なくとも1つの仕掛品（WIP）決定が示される。LWEモジュール216は最初のロット・サイズを調節した後で、LWEモジュール216は特定タイプのアイテムの在庫量対仕掛品スループットのようなカーブを決定し、表示することができる。ユーザは、そのカーブに沿ってまたは隣接していろいろなパフォーマンス点を見ることができる。各々の点は、在庫システムが動作可能ないろいろな達成度の尺度(performance measure)と関連する動作点を表す。クライアント116で入力装置126を使って、ユーザはイクスチェンジ・カーブに沿ったまたは隣接した点をハイライトするかまたは選ぶことができる。ユーザが特定の点をハイライトするか、選ぶとき、カーブに沿ったまたは隣接した特定の点と関連する性能データが表示される。特定の点と関連する性能データは、ユーザが選ぶことができる潜在的な仕掛品（WIP）決定を表す。仕掛品（WIP）決定は特定タイプのアイテムに関して仕掛品のスループットを減少させて、特定タイプのアイテムに関して仕掛品のスループットを増やすことを含むが、これに限定されない。

ブロック922の後に、ブロック924が続く。そこにおいて、仕掛品（WIP）決定に対応するユーザ入力は受け取られる。もしユーザが先に述べたようにカーブに沿ってまたは隣接して特定の点を決めるならば、ユーザは入力装置126を介してデータ入力を送ることによって点を選ぶ。クライアント116は、カーブに沿ったまたはカーブに隣接した点に関する仕掛品（WIP）決定に対応している関連情報を送信する。

ブロック924の後に、ブロック926が続く。そこにおいて、仕掛品（WIP）決定に従い、フローパスまたはサプライチェーンの中で特定のアイテムに関して、仕掛品（WIP）決定は実行される。ウェブサイト118はクライアント116からデータ入力を受け取って、データ入力をFPMSアプリケーション・プログラム112に送る。FPMSアプリケーション・プログラム112は命令を、ユーザによって選ばれた仕掛品(WIP)決定に対応するフローパスまたはサプライチェーンに送る。

ブロック926の後にブロック928が続く。そこにおいて、方法918は終わる。

方法900、918がフローパスまたはサプライチェーンの中でいくつかまたは全てのアイテムのために実行されうる点に注意する。図9Aの方法900はサプライチェーンで複数タイプのアイテムのために実行されることができ、そこでは、サプライチェーンの中で、異なるタイプのアイテムが取り扱われることができるか、さもなければ処理されることができる。そのような場合、他のタイプのアイテムに関してそれぞれのルーティング・データを受けて、それぞれのルーティング・データを格納して、それぞれのルーティング・データに基づくサイクル・タイムを決定して、それぞれの選ばれたサイクル・タイムを決定して、そして他のタイプのアイテムに関してそれぞれのルーティング・データの一部を表示するための更なる機能ブロックが、実行されうる。同様に、方法918は必要に応じてそれぞれのタイプのアイテムに関して必要に応じて実行されうる。

図10は、本発明のいろいろな実施例に従う方法およびシステムの典型的なユーザインタフェースのスクリーン・ショットの上部である。スクリーン・ショットの上部は、フロー・ポイント・マネジメント・システム（FPMS）アプリケーション・プログラム112と関連するLWEモジュール216のユーザインタフェース1000を例示する。LWEモジュール216は、ユーザインタフェース1000を提供する。ユーザインタフェース1000は、選択データのようなユーザ入力を受け取る一連の選択デバイス1002〜1014を含む。各々の選択デバイス1002〜1014は、選択データ（例えばフローパス1002、セーブデータ1004、1006、デルタWIP 1008、ジョブ数1010、WIPテスト数1012とセーブ最適ロット・サイズ1014）を受け取る。たとえば、ユーザインタフェース500は、ネットワーク102と通信可能なウェブサーバ108によってホストされているウェブサイト118において、LWEモジュール216によって表示されうる。ユーザ・オペレーティング・クライアント116は、ブラウザー・アプリケーション・プログラム124を経てユーザインタフェース1000にアクセスすることができる。入力装置126を通して入力されるユーザ入力は、選択デバイス1002〜1014によって受け取られる。例えば、示される例では、ユーザはデルタWIPに対応している選択デバイス1008へ数「5」、ジョブ数に対応している選択デバイス1010へ数「300」、およびWIPテスト数に対応している選択デバイス1012へ数「100」を入力することができた。他の数または量が、エンター又はインプットされてもよい。選択デバイスは、プル・ダウン・メニュー、テキスト・フィールド、ボタン、ラジオ・ボタンまたは他の類似したデバイスを含むが、これに限定されない。さまざまなタイプの選択データを集める他の選択デバイスが、本発明の実施例に従って利用されうる点に注意する。

ユーザインタフェース1000は、在庫データを表示するための一連の表示デバイス1016〜1030も含む。各々の表示デバイス1016〜1030は、LWEモジュール216（例えば、ワーク・センターID 1016、ワーク・センター説明1018、利用率1020、部品番号1022、部品説明1024、需要量1026、現在のロット・サイズ1028と最適ロット・サイズ1030）から、表示データを受け取る。

この例では、LWEモジュール216は、表示デバイス1016を通してワーク・センターIDに関して表示データを表示する。ワーク・センターIDは、フローパスまたはサプライチェーンの中で特定のステーションに対応して1、2、3、4などと番号付けられうる。他のユニークな識別文字を使うこともできる。計量、ブレンド、タブレットおよびパッケージなどの表示データが、また、表示デバイス1018を介してワーク・センターID説明に関してLWEモジュール216によって表示されうる。他の説明が使われてもよい。ルーティング・データおよび／または選択データを用いたLWEモジュール216によって決定される利用率は、表示デバイス1020によって表示されうる。部品番号は、1、2、3、などのように順番に番号付けされてもよく、また別の方法でユニークに特定されてもよい。部品番号説明に対する表示データは、表示デバイス1024を通してLWEモジュール216によって表示されうる。ルーティング・データおよび／または選択データを用いて在庫アドバイザー・モジュール210によって決定される需要値は、表示デバイス1026を通して表示されうる。在庫アドバイザー・モジュール210によって決定される現在のロット・サイズは、表示デバイス1028を通して表示されうる。最適ロット・サイズ値は、ルーティング・データおよび／または選択データを用いて在庫アドバイザー・モジュール210によって決定され、表示デバイス1030を通して表示されうる。

この例では、示される各々のワーク・センターIDと説明のために、LWEモジュール216がルーティング・データおよび／またはユーザ選択データに部分的に基づく利用率を決定する点に注意する。それぞれの利用率は、それぞれ表示デバイス1020に示される。同様に、示される各々の部品番号と部品説明に対して、LWEモジュール216は、需要量、現在のロット・サイズ、およびルーティング・データおよび／またはユーザ選択データに部分的に基づく最適ロット・サイズを決定する。それぞれの需要品質、現在のロット・サイズおよび最適ロット・サイズは、それぞれ表示デバイス1026、1028、1030に示される。

選択デバイス1004、1006および1014を通して、ユーザは特定の部品またはアイテムに対するロット・サイズと関連する表示されたデータの一部または全部をセーブしてもよい。この例では、ユーザは選択デバイス1004への入力を入力することによって利用率を保存してもよい。そして、それは後の参考のために表示されたデータの一部または全部を保存する。LWEモジュール216は、以降の使用または参照のために、表示されたデータを、リレーショナル・データベース106、メモリ114または別のメモリまたはデータストレージ・デバイスに記憶する。同様に、需要、現在のロット・サイズおよび最適ロット・サイズと関連するデータは、選択デバイス1006および／または1014への入力を入力することによって記憶されてもよい。

図11は、図10に示されるスクリーン・ショットの下部である。スクリーン・ショットの下部は、フロー・ポイント・マネジメントシステム（FPMS）アプリケーション・プログラム112と関連するLWEモジュール216のためのユーザインタフェース1100を例示する。LWEモジュール216は、ユーザインタフェース1100を提供する。ユーザインタフェース1100は、選択データのようなユーザ入力を受け取るための一連の選択デバイス1102〜1108およびユーザによるビューイングのためにデータを表示するための一つ以上の表示デバイス1110、1112を含む。選択デバイス1006〜1014および図5に示されるユーザインタフェース1000の表示デバイス1022〜1030は、また、このスクリーン・ショットの中で見られてもよい。

スクリーン・インターフェース1100も、表示デバイス1110〜1112に示される一つ以上のカーブを含む。LWEモジュール216は、部分的にモジュール216によって受け取られるルーティング・データに基く一つ以上のカーブ、およびいくつかの例では選択デバイス1002、1008〜1012、1102〜1106を通して受け取られるデータ選択データに基づく一つ以上のカーブを決定する。カーブがルーティング・データおよび／または選択データの特定の集合に対して決定されるとき、LWEモジュール216は選択デバイス1102〜1108に隣接する対応表示デバイス1110、1112上にカーブを表示する。

この例では、選択データは、選択デバイス1102によって表示デバイス1110内のグラフィック・プロットの単位に関して受け取られてもよい。表示デバイス1110内のグラフィック・プロットの単位と関連する選択データのためのオプションは、標準単位、定義済み単位および利用者定義単位を含むことができるが、それらに制限されない。選択データは、また、選択デバイス1104を通してロット・サイズに関して受け取られてもよい。ロット・サイズと関連する選択データのオプションは、最適ロット・サイズ、現在のロット・サイズ、定義済みロット・サイズおよび利用者定義ロット・サイズを含むことができるが、それらに制限されない。選択データは、選択デバイス1106を通して表示デバイス1112内のグラフィック・プロットの単位に関して受け取られてもよい。表示デバイス1112内のグラフィック・プロットの単位と関連する選択データのオプションは、標準単位、定義済み単位および利用者定義単位を含むことができるが、それらに制限されない。選択デバイス1108を通して、カーブのようなロット・サイズ関係をプロットまたはグラフにしようとするユーザの要望と関連する選択データは、入れられうる。この例では、ユーザは選択デバイス1002、1008-1012、1102-1106のどんな組合せによって新しい選択データを入力してもよく、それから、選択デバイス1108を通して新しい選択データに基づくカーブを要請することができる。LWEモジュール216は新しい選択データを受けて、新しい選択データに部分的に基づいて表示デバイス1110、1112に示される一つ以上のカーブを更新する。

この例で表示デバイス1110, 1112に示されるカーブは、スループット対仕掛品およびサイクル・タイム対仕掛品をそれぞれ例示する。表示デバイス1110に示される第１のカーブは、横x軸1114に沿った仕掛品の量および縦y軸1116に沿ったスループットの量を含む。カーブは、ルーティング・データおよび選択データの特定のセットについて、各々の軸1114、1116に対してプロットされる。ユーザは、それからカーブに沿ってまたは隣接して特定のポイントを選ぶことができ、表示デバイス1110に示されるカーブに基づく仕掛品決定をすることができる。同様に、表示デバイス1112に示される第２のカーブは、横x軸1118に沿った仕掛品の量および縦y軸1120に沿ったサイクル・タイムを含む。カーブは、ルーティング・データおよび選択データの特定のセットについて、各々の軸1118、1120に対してプロットされる。ユーザは、それから表示デバイス1112に示されるカーブに沿ってまたは隣接して特定のポイントを選ぶことができ、表示デバイス1112に示されるカーブに基づく仕掛品決定を選ぶことができる。他のタイプのカーブが、ルーティング・データおよび／または選択データ基づいてLWEモジュール216によってプロットされ、そして表示されうる点に注意する。仕掛品決定は、アイテムの特定タイプに関して仕掛品のスループットを減少させ、アイテムの特定タイプに関して仕掛品のスループットを増加させることを含むが、これに限定されるものではない。

図2を参照して、FPMSアプリケーション・プログラムと関連する他のモジュールは、約束日ファインダー（PDF）モジュール222である。PDFモジュール222は、入って来るオーダーに対して約束データ(promise data)を決定するのに適している。PDFモジュール222は、購入されたコンポーネントの顧客に対して、十分なキャパシティおよび時間どおりの配達の両方を確実にする実行可能な約束日を決定するのにさらに適している。従来の資材所要量計画-タイプおよびキャパシティ要件プランニング-タイプ（CRP）システムと違って、PDFモジュール222は、これらのタイプの分析の両方を同時に実行するのに適している。例えば、PDFモジュール222が購入部品を管理するために在庫システムで利用されるとき、PDFモジュール222は、一定のリード・タイムが適切であるという仮定を用いて資材所要量計画-タイプ・システムと類似して動作する。有効な日付を決定するとき、それが現在存在するように、PDFモジュール222は在庫システムを考慮するのに適している。PDFモジュール222は、サイクル・タイムを最小にするLWEモジュール216からロットサイズ・データを受け取るのにさらに適している。ゆえに、もし状況が変われば、期日はもはや実行可能でないかもしれないが、出荷決定品は最新の情報を使用して決定されうる。

さらに、一旦実行可能なスケジュールが適当になされると、PDFモジュール222はどんな新規受注についても、それらが注文されるときに、チェックするのに適している。例えば、オーダーエントリ機能は、図1に示されるウェブサイト118へ移動可能で、そこでは、ユーザは、優先サービスに対するユーザの要求および支払い意志に基づく商品またはアイテムの望ましい配送日を選ぶことができた。

PDFモジュール222は、在庫システムでリリース・ジョブを管理するのに適している。ERP内の資材所要量計画と違って、PDFモジュール222は、ジョブを「リリース」日付に基づくラインに、押し込まない。その代わりに、PDFモジュール222は、ジョブをCONWIP-タイプ・プロトコルを使用しているラインに「引く(pull)」。この種のプロトコルは単純で、有効である。一例として、図8で示すように、15のロットがラインにあるならば、増加している仕掛品（WIP）はスループットを増やすために何もしない。それは、しかし、サイクル・タイムを大いに増やす。従って、この場合のCONWIPレベルは、15ロットである。ロットの数がおよそ15より下に落ちるときはいつでも、新しいロットはPDFモジュール222によって開始されることができた。結果は、ほぼ一定の仕掛品レベル、別名「CONWIP」である。CONWIP-タイプ・プロトコルは、所定のWIP制限に対するスループットに関して大部分の他の在庫および製品ディスパッチ・システムを上回ることが示され、そして比較的簡単に実行できる。その理由は、WIPレベルが下がる前に、ワークをリリースすることは、ボトルネック資源の前に列を追加するだけであるということである。WIPレベルが減少するまで待った場合よりも早く、ロットが何かを終えることは通常ないだろう。早期にリリースすることによって、全体的な柔軟性（すなわち、リリースされるものを変える能力）と、さらにCONWIP-タイプ・システムの予測性に損失が生じる。PDFモジュール222およびFPMSアプリケーション・プログラム112がKanban-タイプまたはCONWIP-タイプ・システムとともに会社のために同程度によく機能する点に注意する。

PDFモジュール206は、さらにジョブをディスパッチすることに適している。例えば、PDFモジュール206は、一組のジョブに連続した数を割り当てる。連続した数の割当は、期日および重要な要件（例えばアセンブリ・システム）に基づくジョブの望ましいフィニッシュシーケンスを示す、より低い数は差し迫った期日および重要性がより高い要件の一方または両方を示す。フローパスの中での通過のために、ジョブはこのシーケンスどおりに必ずしも終了しないけれども、シーケンスは列の中のどのジョブが次に実行されるべきかを選ぶ一つの方法を提供する。PDFモジュール206は、それから各々のジョブに対する「予想」完了タイムを決定する。予想完了タイムとさらに安全係数に基づいて、PDFモジュール206は、約束日を決定する。期日までの完成について同じ確率を提供する安全係数を使用して期日を特定することは、サービス上の制約を前提として予想され見積もられるリード・タイムを最小にすることに関して最適である。このように、PDFモジュール206は、配送日をチェックし、見積もり、そして重要な入手しやすさを決定するために使用される。

PDFモジュール222は、リアルタイムに顧客に配送日を決定して示すのにさらに適している。これは、資材所要量計画-タイプ・システムによってすでに生成されたスケジュールを最適化するためにコンピュータのロングランを必要とするアドバンスドプランニングアンドスケジューリング（APS）システムと対照をなす。従って、PDFモジュール222は、非常に安易な「約束可能な」ロジックを使用して注文を受け入れ、それから、複雑で冗長な最適化手順を使用して出来が悪いかまたは効率が悪いスケジュールを修理しようとする代わりに、実行可能で、効率的なスケジュールを決定する。そのような処理法はPDFモジュール222によって提供されてもよく、補助なしでネットワーク102を経て顧客によって直接アクセスされてもよい。このように、現実的な出荷日及び効率的で実行可能なスケジュールが、決定されうる。

PDFモジュール222によって実行される一組のアルゴリズムの例は、以下の通りである。後述するアルゴリズムの一部または全部を含む他のアルゴリズムも使用されうる。

現存のジョブはi =1,...,Nとしるされ、ステーションはj=1,...Jとしるされる。潜在的な約束日に対して期間(time periods) k=1,...,Kが定められ、容量計算に対して同じ期間 p=1,...,Kが示される。この例では、4つのデータ入力がある：
m_ij-ステーションjでの製品iのための平均作業時間（部品あたりの時間）
s_ij -ステーションjでの製品iのための平均セットアップ時間（セットアップあたりの時間）
a_jp−単一期間pにおけるステーションjでの製品のために有効な時間（これは各期間で有効なキャパシティであって、各期間p=1,…,Kの間の入力である。）
Di - ジョブiのための期限日ピリオド(due date period)。

各々のステーションjに関して、ステーションjでのピリオドkまでの「累積的な有効キャパシティ」が、

として決定されうる。既存の注文に関する「予約されたキャパシティ」の計算は、新たな注文を受け入れる前に実行される4つの計算ステップを含む。最初に、過去の実際のサイクル・タイムを用いて、また、もし有効であるならば、LWEモジュール216に関して上に記述したサイクル・タイムに類似した近似値を用いて、各ステーション後の各ジョブの「残りのサイクル・タイム」Fijが見積もられる。次に、各ステーションjでの、各ジョブiに関する「最新のタスク完成日」が決定される：

次に、各ピリオドpにおける、各ステーションjでの「予約された時間(hours booked)」は、特定のピリオド内に特定のステーションを訪れるべき全ジョブのために必要な時間を加えることによって計算される：

ここでは、もしジョブ i がピリオドp（T_ij = p）内にステーションjを訪れたらN_ijp = 1、そうでなければN_ijp = 0。（類似したジョブの間でセットアッププーリングを仮定しない場合、これがセットアップ時間の控えめな見積もりである点に注意する。）最後に、各ピリオドkを通しての各ステーションjでの「累積的な予約されたキャパシティ」が、計算される：

それから、新規受注のためにまだ予約されておらずかつまだ有効な時間を決定するために、累積的な有効キャパシティと予約されたキャパシティとの差が、計算される。ピリオドkによって完了されるべきである、入って来るジョブiのために予約可能な量を決定するために、以下の方程式が使用される：

ここで、t=k-F_ijは、ステーションjの後ろに残存しているジョブiに対して予想されるサイクル・タイムをオフセットするために計算される、そして、V_iはジョブiによって訪問されるステーションのセットである。

各ピリオドで約束されうる量を知ることによって、見積もられうる「最小リード・タイム」は決定される。検索は、それから、最大の（最新の）ピリオドk_max（ここで

）を見つけるために、全ピリオドにわたって実行される。もし後のピリオドが「累積的な予約されていないキャパシティ」を持たないならば、この検索は「予約されていないキャパシティ」を持つ初期のピリオドを迂回するという効果がある。「最小リード・タイム」は、以下のピリオドまたはk_max + 1である。

ゆえに、これらまたは他のアルゴリズムを使用して、PDFモジュール222は、キャパシティおよびオーダー・ブック情報を検索することができる。全ての入って来る注文に対するリード・タイムは、また、保証キャパシティが要求ワーク・センターに存在すると見積もられうる。少なくとも1つの例では、ある会社の配達パフォーマンスは、およそ65%から95%まで増加した（部分的にはオーバー・ブッキング・キャパシティ(overbooking capacity)を最小にするPDFモジュール222の能力による）。

図12に、本発明のいろいろな実施例に従う他の典型的な方法1200が示される。方法1200は、あるサプライチェーンでアイテムを生産する際にあるジョブに対して約束日を決定するのに適している。示される実施例において、方法1200は、図1で100として示されるシステム実施例によって実行されうる。一例として、図1に示されるシステム100の要素が参照されるだろう。

ブロック1202で、本方法1200は始まる。ブロック1202の後にブロック1204が続く。そこにおいて、あるステーションでのアイテムの生産時間が決定される。PDFモジュール206は、ERPアプリケーション・プログラム140、メモリ114, 142、リレーショナル・データベース106, 144、ネットワーク102、ユーザまたは他のソースから受け取られる性能データ、ルーティング・データおよび／または選択データからあるステーションでのアイテムの生産時間を決定する。例えば、生産時間を決定するために使用されるデータは、アルゴリズム4.1-4.4 に関して上に記述される。他のアルゴリズムが、発明のいろいろな実施例に従って使用されることができた。

ブロック1204の後にブロック1206が続く。そこにおいて、ステーションでのアイテムのセットアップ時間は決定される。PDFモジュール206は、ERPアプリケーション・プログラム140、メモリ114, 142、リレーショナル・データベース106, 144、ネットワーク102、ユーザまたは他のソースから受け取られる性能データ、ルーティング・データおよび／または選択データからあるステーションでのアイテムのセットアップ時間を決定する。例えば、セットアップ時間を決定するために使用されるデータは、アルゴリズム4.1-4.4 に関して上に記述される。他のアルゴリズムが、発明のいろいろな実施例に従って使用されることができた。

ブロック1206の後にブロック1208が続く。そこにおいて、累積的な有効キャパシティは決定される。PDFモジュール206は、ERPアプリケーション・プログラム140、メモリ114, 142、リレーショナル・データベース106, 144、ネットワーク102、ユーザまたは他のソースから受け取られる性能データ、ルーティング・データおよび／または選択データから累積的な有効キャパシティを決定する。例えば、累積的な有効キャパシティを決定するために使用されるデータは、アルゴリズム4.1-4.4に関して上に記述される。他のアルゴリズムが、発明のいろいろな実施例に従って使用されることができた。

ブロック1208の後にブロック1210が続く。そこにおいて、予約されたキャパシティが決定される。PDFモジュール206は、ERPアプリケーション・プログラム140、メモリ114, 142、リレーショナル・データベース106, 144、ネットワーク102、ユーザまたは他のソースから受け取られる性能データ、ルーティング・データおよび／または選択データから予約されたキャパシティを決定する。例えば、予約されたキャパシティを決定するために使用されるデータは、アルゴリズム4.1-4.4 に関して上に記述される。他のアルゴリズムは、本発明のいろいろな実施例に従って使用されることができた。

ブロック1210の後にブロック1212が続く、そこでは、累積的な有効キャパシティと予約されたキャパシティとの差が決定され、それから前記差は少なくともステーションでのアイテムの生産時間およびステーションでのアイテムのセットアップ時間によって調整される。PDFモジュール206は、それぞれブロック1208と1210で決定される、累積的な有効キャパシティと予約されたキャパシティとの差を決定する。生産時間およびセットアップ時間（それぞれブロック1204と1206で決定される）に関するデータは、それから、前記の差を調整するために、PDFモジュール206によって使用される。例えば、前記差に対する調整を決定するために使用されるデータは、アルゴリズム4.1-4.4に関して上に記述される。他のアルゴリズムが、本発明のいろいろな実施例に従って使用されることができた。

ブロック1212の後にブロック1214が続く、そこでは、部分的に前記差に基づいて、サプライチェーンにおいてアイテムを生産するジョブに関する最小リード・タイムが決定される。PDFモジュール206は、ERPアプリケーション・プログラム140、メモリ114, 142、リレーショナル・データベース106, 144、ネットワーク102、ユーザまたは他のソースから受け取られる性能データ、ルーティング・データおよび／または選択データを使用している特定のジョブのために、最小リード・タイムを決定する。例えば、累積的な有効キャパシティを決定するために使用されるデータは、アルゴリズム4.1-4.4に関して上に記述される。他のアルゴリズムが、本発明のいろいろな実施例に従って使用されることができた。

ブロック1214の後にブロック1216が続く。そこにおいて、方法1200は終わる。

本発明の好ましい実施例についての前述の説明は、図解および説明だけの目的で示されたものであり、本発明を開示されたそのままの形に制限することを意図するものではない。上記教示内容に照らして、多くの修正および変更が可能である。実施例は、当業者が、発明およびさまざまな実施例およびさまざまな変形例を、予想される実用的な利用に適して、利用可能なように、発明の原理と実用的な適用を説明するために選択され記述された。

図1は、本発明のさまざまな実施例による典型的なシステムの機能ブロック図である。 図2は、本発明のさまざまな実施例による、システムの典型的な計画階層の概念図を例示する。 図3は、本発明の実施例による典型的なシステム及び方法によって提供されるグラフィカルチャートの具体例である。 図4Aは、本発明のさまざまな実施例による典型的な方法のフローチャートである。 図4Bは、本発明のさまざまな実施例によるもう一つの典型的な方法のフローチャートである。 図4Cは、本発明のさまざまな実施例によるもう一つの典型的な方法のフローチャートである。 図5は、本発明のさまざまな実施例による方法およびシステムのための典型的なユーザインタフェースのスクリーン・ショットである。 図6は、図5に示されるスクリーン・ショットの下部である。 図7は、本発明のさまざまな実施例による方法およびシステムのための典型的なユーザインタフェースのもう一つのスクリーン・ショットである。 図8は、本発明の実施例による典型的なシステム及び方法によって提供されるもう一つのグラフィカルチャートの具体例である。 図9Aは、本発明のさまざまな実施例によるもう一つの典型的な方法のフローチャートである。 図9Bは、本発明のさまざまな実施例によるもう一つの典型的な方法のフローチャートである。 図10は、本発明のさまざまな実施例による方法およびシステムのためのもう一つの典型的なユーザインタフェースのスクリーン・ショットである。 図11は、図10に示されるスクリーン・ショットの下部である。 図12は、本発明のさまざまな実施例によるもう一つの典型的な方法のフローチャートである。

Claims (22)

1. サプライチェーンにおいて類似したアイテムの在庫を管理する方法であって：
   (a) フローパスが少なくとも1つのオペレーションを含むサプライチェーンにおいてアイテムに関してフローパスを決定すること;
   (b) 各々のオペレーションで前記アイテムに関して在庫データを受け取ること;
   (c) 前記在庫データを記憶すること;
   (d) 前記アイテムに関して需要要因を決定すること;
   (e) 前記アイテムに関してコスト要因を決定すること;
   (f) 前記需要要因および前記コスト要因に部分的に基づいて、前記アイテムに関してイクスチェンジ・カーブを決定すること;および
   (g)前記イクスチェンジ・カーブおよび前記アイテムに関して前記在庫データの一部を表示すること、を含む方法。
2. 請求項１の方法であって、更に：
   (h) 前記サプライチェーンの中で前記アイテムに関して少なくとも1つの在庫決定を表示すること;
   (i) 前記在庫決定に対応しているユーザ入力を受け取ること;および
   (j)前記在庫決定に従い、オペレーションで前記アイテムに関して前記在庫決定を実行すること、を含む方法。
3. 前記在庫決定は、注文に応じたアイテム製造および在庫のためのアイテム製造から成るグループから選ばれる、請求項２の方法。
4. (d) 前記アイテムに関して需要要因を決定することは、あらかじめ定義された総時間にわたって前記アイテムに関する注文数を決定することを含む、請求項１の方法。
5. (e) 前記アイテムに関してコスト要因を決定することは、前記アイテムに関して総サイクルストック・コストを決定することを含む、請求項１の方法。
6. (f) 前記需要要因および前記コスト要因に部分的に基づいて、前記アイテムに関してイクスチェンジ・カーブを決定することは、
   前記サプライチェーンにおける前記アイテムのサイクルストック在庫コストを、あらかじめ定義された期間にわたる前記アイテムに対する注文数と比較することを含む、請求項１の方法。
7. (f) 前記需要要因および前記コスト要因に部分的に基づいて、前記アイテムに関してイクスチェンジ・カーブを決定することは、
   前記アイテムに関して複数のイクスチェンジ・カーブを決定することを含む、請求項１の方法。
8. (k) 前記アイテムに関するリオーダ点およびリオーダ量を決定することをさらに含む、請求項２の方法。
9. (h)あらかじめ定義された総時間の期間にわたって予想される品切れ数と安全在庫への投資を決定すること;
   (i)あらかじめ定義された総時間の期間あたりの前記予想される品切れ数と前記安全在庫への投資に基づいてペナルティ・コスト曲線を決定すること;および
   (j) 前記ペナルティ・コスト曲線および前記アイテムに関する在庫データの一部を表示することをさらに含む請求項１の方法。
10. サプライチェーンにおいて異なるタイプのアイテムの在庫を管理する方法であって：
    (a) オペレーションで第１のタイプのアイテムに関して在庫データを受け取ること;
    (b) オペレーションで第２のタイプのアイテムに関して在庫データを受け取ること;
    (c) 前記第１のタイプおよび前記第２のタイプのアイテムに関して前記在庫データを記憶すること;
    (d) 前記第１のタイプおよび前記第２のタイプのアイテムに関して需要要因を決定すること;
    (e) 前記第１のタイプおよび前記第２のタイプのアイテムに関してコスト要因を決定すること;
    (f) 前記需要要因および前記コスト要因に部分的に基づいて、第１のタイプのアイテムに関する第１のイクスチェンジ・カーブおよび第２のタイプのアイテムに関する第２のイクスチェンジ・カーブを決定すること;および
    (g) 第１および第２のタイプのアイテムに関する在庫データの一部および第１および第２のタイプのアイテムに関するイクスチェンジ・カーブを表示することを含む。
11. 少なくとも１つのステーションを含むサプライチェーンにおいて類似したアイテムのロット・サイズを管理する方法であって：
    (a) 第１のステーションでアイテムに関して初期ロット・サイズを決定すること;
    (b) 各々のステーションでアイテムに関してルーティング・データを受け取ること;
    (c) 前記ルーティング・データを記憶すること;
    (d) 前記ルーティング・データに基づいて、前記第１のステーションから前記サプライチェーン中を流れている前記アイテムに関してサイクル・タイムを決定すること;
    (e) 前記第１のステーションから前記サプライチェーン中を流れている前記アイテムに関する前記サイクル・タイムに少なくとも基づいて、前記アイテムに対して望ましいサイクル・タイムを選ぶこと;および
    (g) 前記アイテムに対して前記選ばれた望ましいサイクル・タイムに少なくとも基づいて、前記第１のステーションで前記アイテムに対する前記初期ロット・サイズを調節することを含む。
12. 少なくとも１つのステーションを含むサプライチェーンにおいて複数タイプのアイテムのロット・サイズを管理する方法であって：
    (a) 第１のステーションで第１のタイプのアイテムに関して初期ロット・サイズを決定すること;
    (b) 前記第１のステーションで第２のタイプのアイテムに関して初期ロット・サイズを決定すること;
    (c) 前記アイテムが前記第１のステーションから前記サプライチェーンを通して流れるとき、各々のタイプのアイテムに関してルーティング・データを受け取ること;
    (d) 前記ルーティング・データを記憶すること;
    (e) 前記ルーティング・データに基づいて、前記サプライチェーン中を前記第１のステーションから流れているアイテムの各々のタイプに関してサイクル・タイムを決定すること;
    (f) 前記サプライチェーン中を前記第１のステーションから流れている前記アイテムに対する前記サイクル・タイムに少なくとも基づいて、各々のタイプのアイテムに関して望ましいサイクル・タイムを選ぶこと; および
    (g) 各々のタイプのアイテムに関する前記望ましいサイクル・タイムに少なくとも基づいて、前記第１のステーションで各々のタイプのアイテムに関して初期ロット・サイズを調節することを含む。
13. 必要に応じて前記要素(a)−（g）を反復することをさらに含む請求項１２の方法。
14. 前記選ばれた望ましいサイクル・タイムが、前記サプライチェーン中を前記第１のステーションから流れている第１のアイテムの前記初期サイクル・タイムより低い、請求項１２の方法。
15. (h) 少なくともルーティング・データの一部に基づいて、第２のステーションで処理される第１のタイプのアイテムの量および第１のステーションから前記アイテムが流れるときの前記第１のタイプのアイテムの仕掛品のスループットを決定すること; および
    (i) ルーティング・データの一部、前記サプライチェーンにおける他のステーションで処理された前記第１のタイプのアイテムの数、および前記サプライチェーンにおいて前記第１のステーションから前記他のステーションまで前記アイテムが流れるとき、前記第１のタイプのアイテムの仕掛品のスループットを表示することをさらに含む請求項１２の方法。
16. (h) 前記第１のタイプのアイテムに関して少なくとも1つの仕掛品決定を表示すること;
    (i) 前記仕掛品決定に対応するユーザ入力を受け取ること; および
    (j) 前記第１のステーションで前記第１のタイプのアイテムに関して、前記仕掛品決定を実行することをさらに含む請求項１２の方法。
17. 前記第１のタイプのアイテムに関して仕掛品の前記スループットを減少させること、および前記第１のタイプのアイテムに関して仕掛品の前記スループットを増やすことからなるグループから、前記仕掛品決定が選ばれる、請求項１６の方法。
18. 入って来るオーダーに関して約束日を決定する方法であって、サプライチェーンは少なくとも１つのステーションを含み：
    (a) ステーションでアイテムに関して生産時間を決定すること;
    (b) 前記ステーションで前記アイテムに関してセットアップ時間を決定すること;
    (c) 累積的な有効キャパシティを決定すること;
    (d) 予約されたキャパシティを決定すること;
    (e) 前記累積的な有効キャパシティと予約されたキャパシティとの差を決定すること、および
    少なくとも前記ステーションでアイテムに関する前記生産時間および前記ステーションで前記アイテムに関するセットアップ時間によって前記差を調節すること; および
    (f)前記差に部分的に基づいて、入って来る注文に関して最小リード・タイムを決定することを含む。
19. (c) 累積的な有効キャパシティを決定することが、予め定義された総時間にわたって前記ステーションで前記アイテムのさらなる製造のために使用可能な時間を決定することを含む請求項18の方法。
20. (d）予約されたキャパシティを決定することが：
    (1) 前記ステーションの後で各々の注文のために残り時間を決定すること;
    (2) 前記ステーションで各々の注文の最新のタスク完成日を決定すること;
    (3) 予め定義された総時間にわたって前記ステーションで予約された注文時間を決定すること; および
    (4) 第２の予め定義された総時間のために、前記ステーションで累積的な予約されたキャパシティを決定すること、を含む請求項１８の方法。
21. 複数のアイテムに関してサプライチェーンを管理する方法であって：
    (a) 各々のフローパスが複数のオペレーションを含むサプライチェーンにおいて各々のタイプのアイテムに関してフローパスを決定すること;
    (b) 各々のオペレーションで各々のタイプのアイテムに関して性能データを受け取ること;
    (c) 前記性能データを記憶すること;
    (d) イクスチェンジ・カーブ、ロット・サイズ見積り、および約束日からなるグループから選択された決定を得るために前記性能データを処理すること;
    (e) 前記アイテムおよび前記決定に関して前記性能データの一部を表示する。
22. 複数タイプのアイテムに関するサプライチェーンを管理するためのシステムであって：
    各々のフローパスが複数のオペレーションから成るサプライチェーンにおいて、各々のタイプのアイテムに関してフローパスを決定する;
    各々のオペレーションで各々のタイプのアイテムに関して性能データを受け取る;
    前記性能データを記憶する;
    イクスチェンジ・カーブ、ロット・サイズ見積り、および約束日からなるグループから選ばれる決定を得るために、前記性能データを処理する; および
    前記アイテムおよび前記決定に関して前記性能データの一部を表示する、ことに適したフローパス・マネジメントシステム・モジュールを含む。

Images