Oracle Service Parts Planningインプリメンテーションおよびユーザー・ガイド リリース12.1 B70972-01

目次

前へ

次へ

サービス計画の概念

この章では、次のトピックを説明します。

• 供給計画としての返品予測
• 返品予測リリーフ - 返品予測タイム・フェンス–
• 修理計画のリード・タイム
• 部品条件に基づいた計画
• 交替品目関連
• 交替部品検索ロジック
• 交替チェーンでの計画オーダーの生成
• 交替品目関連が母集団基準の予測に与える影響
• 在庫残高再計算 - 循環ソーシング–
• 需要優先度
• リバース・ロジスティクス割当セット
• ソース・ルール「戻る」の割当て
• ソース・ルール「修理場所」の割当て
• ソース・ルールおよびランク
• ソース・ルールと交替品目属性
• 代替出荷方法
• 有効な制約
• コスト・ベースの最適化
• 原価の最適化の有効化
• 予約のサポート
• オーダー・モディファイアおよびリバース・サプライ・チェーン
• 新規部品番号としての再生部品の設定
• 再発注点ベースの計画
• 供給割付ルールの定義
• 品目と組織への供給割付ルールの割当て
• デフォルト割付用計画オプションの設定
• フェア・シェア割付

供給計画としての返品予測

修理可能返品数の予測は、計画で障害品の供給ストリームと見なされます。

DemantraまたはEBSで生成された返品予測をグローバル返品予測としてSPPに含めることができます。この値は、「計画オプション」 →「 スコープ」 →「 組織」タブの右上で設定されます。返品予測は組織固有の供給計画値リストに表示されないため、現在、含めることはできないことに注意してください。

計画に含まれている返品予測は「返品予測」と呼ばれるオーダー・タイプで計画に表示されます。‘’これは、SPPによって、予想される返品の将来のストリームと解釈され、修理の計画で考慮されます。

返品予測リリーフ - 返品予測タイム・フェンス–

返品予測と実際の返品の両方が障害品品目の供給ソースと見なされます。返品が発生している間、返品予測を削減（または消費）しないと、修理用の障害品部品の供給数が過大になる可能性があります。

予測の消費

たとえば、返品予測によって毎月100個の障害品の返品が予測されているとします。今月の残りは8日であり、これまでに87個の障害品が受入れられています。その場合、今月の障害品の総供給量が総予測量プラス実際の返品数（100 + 87 = 187）になる見込みはありません。それよりは、月末までに合計100個の障害品が受入れられる可能性の方が高いでしょう。その数字には、すでに受入れられている87個と今月の予測の残り（100 – 87 = 13）が含まれています。’この時点で、実際に受入れられた数量が予測の大半を消費しています。

この例では、さらに18個の障害品が受入れられますが、その時点で月末まで2日しか残っていません。それまでに実際に受入れられた障害品の合計は（87 + 18 = 105）個です。この時点で、予測は完全に消費されています。月末までに障害品が返品される見込みはありません。

返品予測タイム・フェンス

これより不正確ではあるものの、実際の返品による供給と予測返品による供給のカウントが重複するのを回避する簡単な方法は、タイム・フェンス機能を実装することです。タイム・フェンスでは将来の日付をマークします。現在とタイム・フェンスの間の期間がタイム・フェンス内にあると見なされます。タイム・フェンスは時の経過とともに前進します。つまり、現在の日付とタイム・フェンスの日付との間の日数は常に一定です。

タイム・フェンス機能は、計画を固定することによって、混乱を招く土壇場の勤務スケジュールの変更を回避する目的で製造の現場でよく使用されます。この例で言えば、タイム・フェンス内の期間中、返品予測はゼロに削減されます。そうすることで、タイム・フェンス内の近い将来の期間中に実際の返品による供給と予測された返品による供給の両方のカウントが重複することを回避できます。このタイム・フェンスは、返品予測タイム・フェンスと呼ばれています。

返品予測タイム・フェンスのデフォルト値はゼロです。これは、（計画実行日を含まない）期限を過ぎたすべての返品予測数量が削除され、組織の既存の手持在庫として実現されたと見なすことを意味しています。

バケットが大きい予測の残りの部分を正確に保持するために、返品予測タイム・フェンス内に収まるバケット内の予測数量が稼働日数にわたって均等に分散され、タイム・フェンスを超える有効な予測数量のみがバケット内の残りの日数分だけ保持されます。予測バケット・サイズが2日以上であれば、このシナリオが有効です。

期限を過ぎた返品によるすべての供給およびタイム・フェンス内の供給は、実際の返品の在庫への変換をオフセットするために、計画の時点で自動的に削除されます。計画が返品供給を削除するときは、予測（供給）を分散させ、計画バケットに対して有効な供給の残りの部分のみを保持します。これは、返品予測のバケットが週単位または期単位である場合に有効な要件です。

たとえば、予測が週当たり70個であり、計画が週単位バケット開始日の1日目に実行され、返品予測タイム・フェンス(日数)の属性値がゼロの場合、エンジンは70個の予測量すべてを保持します。計画が5日目に実行される場合、エンジンは当初の予測のうち30個分だけを保持します。次の表でリリーフ機能を説明します。

注意: 計画のための品目属性の管理の詳細は、品目への予測ルールの関連付けを参照してください。

予測の消費と受注

社内受注と社外受注の両方がそれぞれの予測を消費します。現場からの需要は補充組織で社内受注（ISO）として生成されます。これらの品目の予測はローカル予測またはグローバル予測を介して補充組織に供給されます。

グローバル予測が需要として定義されている場合、サプライ・チェーン計画ではソース・ルールに従って需要を分散させます。ソース・ルールおよびランクを参照してください。

補充組織で（現場からの社内購買依頼に対して）発行されたISOは補充組織の予測を消費します。そのISOはアウトバウンド出荷–現場組織と呼ばれます。

グローバル予測技術を使用する場合、サービス・サプライ・チェーンの予測および予測の消費の論理的な順序は次のようになります。

1. グローバル予測を生成します。

2. グローバル・ソース・ルールを使用して予測を適切に割り当てます。

3. 補充組織でのISO（アウトバウンド出荷）による予測の消費を補充組織で実行します。ローカル予測、ゾーン・レベルの予測、グローバル予測のすべてが補充組織内に混在している場合は、まずローカル予測が消費され、次にゾーン・レベルの予測、グローバル予測の順に消費されます。

サービス部品計画での現場組織は、需要予測を生成するプロセスのためにのみ存在します。これらの現場組織は供給計画では考慮されません。現場組織から受入れた社内購買依頼と社内受注（アウトバウンド出荷向け）のみが需要と見なされます。現場組織から発生する他の需要はありません。

修理計画のリード・タイム

製造組織カレンダは修理リード・タイムをオフセットする目的に使用されます。前処理品目リード・タイムと後処理品目リード・タイムは修理組織では考慮されません。

品目-組織属性の修理リード・タイムは、次の3つのリード・タイム要素の合計です。

• 障害品を修理組織へ転送するためのリード・タイム

  計画では、転送ソース・ルールとそれに関連する出荷ネットワークを使用して、障害品を修理組織へ転送するためのリード・タイムを決定します。

• 修理組織で障害品部品を修理するためのリード・タイム

  修理組織での修理工程の期間を表す値として、品目と組織の組合せに対してこのリード・タイム要素を定義します。

• 良品部品を修理組織から購入し、倉庫に（転送および受入れる）ためのリード・タイム

  このリード・タイムは出荷ネットワークに基づいて決まります。これは、良品部品を修理組織（社内または社外）から転送し、倉庫に受入れるためのリード・タイムです。

修理プログラムがサービス・サプライ・チェーンのリード・タイム・オフセットに及ぼす影響

修理プログラムは、修理仕入先から部品を調達するためのリード・タイムに影響を及ぼすため、計画に大幅な影響を及ぼします。スペア管理は、「在庫MPS/MRP計画」タブで特定の品目と修理仕入先の組合せに対して設定される次の修理プログラムをサポートします。

• 修理返品（プル）

  修理発注のオフセットで3つのリード・タイム要素すべてを考慮します。

• 事前配置の修理返品（プッシュ）

  障害品がすでに修理組織の手持在庫になっているため、修理リード・タイム要素と受入リード・タイム要素のみが考慮されます。

• 事前配置参照

  • 発注承認に対する事前交換

    受入リード・タイムのみが考慮されますが、すべての受注ドキュメントが生成されます。この場合、計画では転送リード・タイムと修理リード・タイムをゼロと見なします。

  • 障害品受入に対する事前交換

    転送リード・タイムと受入リード・タイムの両方が考慮されます。その他すべてのドキュメントが生成されます。この場合、計画では修理リード・タイムをゼロと見なします。

  • 事前配置参照

    修理された品目が事前配置され、計画から見えます。受入リード・タイムのみが考慮されますが、すべての関連ドキュメントが生成されます。この場合、計画では転送リード・タイムと修理リード・タイムをゼロと見なします。

事前交換が関係する場合は、障害品在庫が出荷された後、実行プロセスが障害品在庫を管理し、修理仕入先からの部品の受入時に修理組織の在庫勘定から資材を出庫します。

修理プログラムの詳細は、Oracle Spares Management ユーザー・ガイドを参照してください。

部品条件に基づいた計画

社外修理に対する部品条件の想定

社外修理組織では、良品部品用の保管場所と障害品部品用の保管場所を別々にマークします。計画では、デフォルトで、修理構成表内の良品部品が障害品構成部品と同じ部品IDを持っていると想定します。

ソーシングでの修理では、修理仕入先組織で良品部品を探します。修理仕入先組織の構成表体系に従って障害品品目への構成部品需要が生成されます。計画エンジンは転送ソール・ルールに基づいて障害品部品を探します。手持在庫は障害品と想定されており、返品オーダー・タイプも障害品と想定されているため、計画は障害品部品のみを修理のためにプルします。

修理仕入先で想定される部品構成表体系は次のようになります。

修理のために社外の修理仕入先組織へ出荷されたすべての障害品が、障害品としてマークされた仕入先の保管場所へ受入れられます。修理仕入先は、修理オーダーに従って障害品保管場所から部品を移動し、修理を実行し、品目を良品保管場所へ受入れます。修理済部品を倉庫に受入れると、バックフラッシュ取引が必要とされる数量を移動したうえ、良品保管場所から控除します。

歩留損失は、修理仕入先の障害品保管場所で、その他の出庫として廃棄されます。

デポ修理に対する部品条件の想定

計画では、デポ修理組織で良品部品を生産するには障害品部品が必要であると想定します。

注意: 社内デポ修理組織が製造組織と同一である場合に対応するために、サービス部品品目の番号は生産で使用される構成部品品目の番号と異なると想定されています。

障害品部品はデポ修理組織の障害品保管場所へ受入れられます。修理オーダーのバックフラッシュ取引が障害品保管場所から在庫を控除します。

交替品目関連

交替品目はサービス・サプライ・チェーンで考慮されます。製品の設計変更は、交替の定義に基づいて管理される改訂品目を生成します。すべての改訂はOracle E-Business Suiteで新規品目として定義されます。それらの新規品目は、交替品目関連または修理対象品目関連を使用して同じグループに分類されます。

スペア管理では、交替と呼ばれる在庫品目関連を使用して交替チェーンを取得します。さらに、スペア管理を含むフィールド・サービス・モジュールは、修理箇所と呼ばれる品目関連を使用して、修理の結果、障害品部品を上位改訂部品に変換できるかどうかを判断します。

予測や在庫計画を生成するとき、ユーザーは、たいていの場合、置換される部品の需要と供給を考慮しながら、最上位改訂品目を計画します。

交替の定義には計画に関連するパラメータが2つあります。

• 方向: 交替の方向は一方向A -> Bまたは双方向C <- -> Dのどちらかです。許可されている場合、交替検索方向では、まず置換される部品を使い切ります。たとえば、双方向交替C <- -> Dの場合は、上位改訂品目であるDへの需要があったとき、置換される部品Cを使い切ることができます。

• 処分コード: 処分コードは「廃棄」または「使い切り」です。デフォルト値は「使い切り」です。

  処分コードが「廃棄」である場合、ユーザーは置換される部品の良品の手持在庫を手動で算入不可保管場所へ移動します。部品Aを良品部品Bにアップグレードできる場合、ユーザーは、アップグレードのためにプルまたはプッシュできるように、部品Aの手持在庫を部品Bの障害品保管場所へ手動で移動します。

  「使い切り」の場合、その作業は必要とされません。AとBの間に修理対象関連が定義されている限り、障害品Aを自動的に修理して良品Bに変換することができます。

サービス部品計画では、交替方向と処分コードの両方を考慮します。

良品部品のみから構成されるフォワード・サプライ・チェーンでは、交替の定義によって、どの部品を使い切り、どの補充部品を発注するかを決定します。

リバース・サプライ・チェーンでは、定義の「修理箇所」の部分で、歩留損失または修理リード・タイムのない交替チェーンのグローバル修理機能を決定します。現在、交替の定義では、グローバルな交替と修理機能を定義しています。

交替の定義およびサービス部品計画での交替の使用方法については、Oracle Spares Managementユーザー・ガイドを参照してください。

品目関連の定義を参照してください。

交替部品検索ロジック

場所: 検索ロジックの原則は、サプライ・チェーンの他のノードからの供給を使用する前に、ローカルで需要を満たす必要があることです。

改訂: 同じ日に同じオーダー・タイプの複数の品目改訂に対する需要が発生した場合、検索ロジックでは、上位改訂品目への需要を満たす前に、低位改訂品目への需要を満たそうとします。たとえば、交替チェーンがA1 -> A2 -> A3であり、A1、A2、A3への予測需要が同じに日に存在する場合は、A1、A2、A3の順に需要が満たされます。

次の図に示す検索ロジックでは、計画が、サプライ・チェーンの他の部分からの供給を検索し、使用する前に、利用可能で有効なすべての交替部品を使用することによって、需要側組織で需要を満たそうとします。ここで、組織C1で品目A2に対する需要があるとします。

個々の組織内の実際の検索パターンは交替ルールによって管理されます。交替ルールの定義の様々なオプションの意味を理解するために、交替の例をいくつか挙げましょう。

一方向交替および処理コード「使い切り」

品目Bは品目Aを置き換えます。その品目Bは品目Cに置き換えられ、さらに品目Dに置き換えられます。品目Dは最新（最上位）改訂品目であり、品目Aは最古改訂品目です。処理コードは「使い切り」です。計画エンジンは、次の交替ルール・ロジックを使用して、様々な改訂品目の手持在庫と計画受入を使い切ります。

A->B<- ->C->D

上の記号は、B、CまたはDがAへの需要を満たせることを意味しています。AはB、CまたはDへの需要を満たせません。また、BとCは互いの需要を満たせます。

事例1: 前図のサプライ・チェーンでは、地域物流組織DC1で品目Aへの需要が発生すると、計画は次の順番で手持在庫品目と計画受入品目を検索します。

1. DC1の品目A、品目B、品目C、品目D

2. DC2の品目Aの剰余、品目Bの剰余、品目Cの剰余、品目Dの剰余（循環ソース *）

3. 中央スペア倉庫の品目A、品目B、品目C、品目D。

在庫残高再計算 - 循環ソーシング–を参照してください。

事例2: 組織DC1で品目Bへの需要が発生すると、計画は次の順番で手持在庫品目と計画受入品目を検索します。

1. DC1の品目B、品目C、品目D

2. DC2の品目Bの剰余、品目Cの剰余、品目Dの剰余（循環ソース）

3. 中央スペア倉庫の品目B、品目C、品目D

事例3:

組織DC1で品目Cへの需要が発生すると、計画は次の順番で手持在庫品目と計画受入品目を検索します。

1. DC1の品目B、品目C、品目D

2. DC2の品目Bの剰余、品目Cの剰余、品目Dの剰余（循環ソース）

3. 中央スペア倉庫の品目B、品目C、品目D

事例4:

組織DC1で品目Dへの需要が発生すると、計画は次の順番で品目を検索します。

1. DC1の品目D

2. DC2の品目Dの剰余

3. 中央スペア倉庫の品目D

計画が部品Dを最新改訂であると判断し、部品Dに対して双方向関連が定義されていないため、事例4では交替検索が有効になりません。

手持在庫の検索で品目が見つからなくなった場合、計画は修理部品に対する修理対象関連を調べて使用し、その後、新規の発注を行う前に、それらの部品を供給として使用します。

一方向交替および処理コード「廃棄」

この場合、ユーザーは、置換される部品の良品の手持在庫を手動で算入不可保管場所へ移動するか、部品Aを良品Bにアップグレードできる場合は、アップグレードのためにプルまたはプッシュできるように、障害品保管場所へ手動で移動します。

計画は前の例で示したものと同じロジックに従ってサプライ・チェーン内で部品を検索します。

双方向交替および処理コード「使い切り」

品目Aが品目Bに置き換えられており、品目Bが双方向交替によって品目Cと品目Dに置き換えられていて、処理コードが「使い切り」の場合、検索エンジンは次のロジックに基づいて手持在庫と計画受入を使い切ります。

A<- ->B<- ->C<- ->D

この表記は、すべての品目が相互に代替可能であることを意味しています。

事例1: 組織DC1で品目Aへの需要が発生すると、計画は次の順番で手持在庫品目と計画受入品目を検索します。

1. DC1の品目A、品目B、品目C、品目D

2. DC2の品目Aの剰余、品目Bの剰余、品目Cの剰余、品目Dの剰余（循環ソース）

3. 中央スペア倉庫の品目A、品目B、品目C、品目D。

事例2: 組織DC1で品目Bへの需要が発生すると、計画は次の順番で手持在庫品目と計画受入品目を検索します。

1. DC1の品目A、品目B、品目C、品目D

2. DC2の品目Aの剰余、品目Bの剰余、品目Cの剰余、品目Dの剰余（循環ソース）

3. 中央スペア倉庫の品目A、品目B、品目C、品目D。

事例3: DC1で品目Cへの需要が発生すると、計画は次の順番で手持在庫品目と計画受入品目を検索します。

1. DC1の品目A、品目B、品目C、品目D

2. DC2の品目Aの剰余、品目Bの剰余、品目Cの剰余、品目Dの剰余（循環ソース）

3. 中央スペア倉庫の品目A、品目B、品目C、品目D。

双方向交替および処理コード「廃棄」

双方向交替と処理コード「廃棄」の組合せは有効な設定ではありません。

注意: サプライ・チェーンの検索中、計画は「廃棄」処理を考慮しません。

交替チェーンでの計画オーダーの生成

フィールド・サービス、修理、交換の業務では、元の品目供給源または代替供給源を見つけて、定義されている物流チャネル全体に品目を配分することを重点を置きます。品目への需要は、交替チェーン内のいずれかの品目である可能性があります。物流ネットワーク上で供給源が見つからない場合は必要な品目を購入できますが、製造業者が（異なる品目として別の型番が付いている）品目の旧バージョンを生産していない可能性があるため、（異なる品目として別の型番が付いている）古い改訂の品目を購入することはできません。そのような場合は、製品の（異なる品目として別の型番が付いている）最新改訂を購入する必要があります。そのため、計画エンジンでは最上位改訂品目のみの新規購買供給が作成されます。

すべての既存の供給源が考慮された後、新しい部品を調達するための計画オーダーが作成されます。これには、良品供給および障害品（修理後の）供給の両方が含まれます。

交替品目関連が母集団基準の予測に与える影響

Install Baseは交替関連に属する製品を個別に追跡するため、交替の影響を考慮する必要があります。

故障率の影響

製品-サービス部品の故障率は、特定の製品に関する交替チェーン全体のすべての使用履歴を合計し、それを特定の製品の総製品母集団で割って、その計算結果である故障率を最新改訂の製品固有の故障率に当てはめることによって計算できます。

交替関連の例

• サービス部品A ->サービス部品（最新改訂）

• サービス部品Aは製品X、製品Yで使用されています

  • サービス部品Aの使用量 – 製品X: 5

  • サービス部品Aの使用量 – 製品Y: 10

• サービス部品Bは製品X、製品Yで使用されています

  • サービス部品Bの使用量 – 製品X: 7

  • サービス部品Bの使用量 – 製品Y: 12

• 製品Xの総母集団: 100

• 製品Yの総母集団: 125

• サービス部品Bの平均故障率 – 製品X: (7+5)/100 = 0.12

• サービス部品Bの平均故障率 – 製品Y: (10+12)/125 = 0.176

収集の影響

製品のInstall Base母集団情報は使用量情報とともに収集されます。Install Baseで追跡される組織は、Install Base情報を選択的に収集できるように、インスタンス設定ウィンドウでInstall Base組織として指定されます。

サービス部品と製品の関係を判断できるように、製品とサービス部品の関連が収集されます。この関連は直接は表示されませんが、この製品固有の情報は「故障率」（および「返品率」）ウィンドウまたは予測分析ビューで見ることができます。

レガシーInstall Baseの履歴、故障率、返品率をロードすることができます。

インタラクティブな計画の影響

予測分析ビューで故障率を編集できます。故障率または製品固有の母集団を変更したときは、更新された故障率および返品率に基づいて予測を再計画および再計算できます。手動で予測を上書きすることもできます。

ソース・ルールと交替品目属性を参照してください。

在庫残高再計算 - 循環ソーシング

顧客満足を高めるために、サービス・サプライ・チェーンでは地域倉庫などの戦略的な場所に在庫を持ちます。需要が変化するため、様々な場所に存在する倉庫にまたがって在庫残高を再計算する必要が生じることがあります。循環ソーシングと通常のソーシングの主な違いは、循環ソースでは指定されたタイム・フェンス内で必要とされない余分な（つまり剰余）在庫がある場合にのみサプライ・チェーンの補充に参加することです。

在庫残高を再計算するときは、次のことを考慮します。

• 循環ソーシング – 選択的に有効になっているかどうか

• オーダー数量モディファイア – オーダー・モディファイアを考慮することが転送元での最小数量の違反になる場合、在庫転送はお薦めできません。

• 同時リバース転送 – 指定されたタイム・フェンス内でリバース転送またはネイティブ需要が発生する場合、在庫転送はお薦めできません。

• 転送原価 – 転送原価が在庫保管費より高い場合、プロセスが転送オーダーを生成することはできません。

たとえば、循環ソーシング関連がEastとCentralという2つの組織の間に設定されているとします。一方の組織で品切れが発生した場合、他方の組織を供給ソースとして計画に使用させることができれば便利です。

循環ソーシング関連とは、EastからCentralへ、またはCentralからEastへの転送を作成できることを意味しています。在庫が2つのサイトの間を継続的に循環することを防止するために、サービス部品計画のロジックは、同じバケット内または複数のバケット間では双方向に転送を作成しません。

2つの組織に対して2つのローカル・ソース・ルールを定義し、「循環」チェック・ボックスをオンにして循環関連を指定することによって、循環ソーシング関連を作成します。ソース・ルールの例を2つ示します。

前の例では、R1のローカル・ソース・ルールとR2のローカル・ソース・ルールの両方で「循環」をオンにすることによって、R1とR2の間に循環関連が指定されています。有効な循環ソーシング関連を確立するには、両方の転送方向を指定する必要があります。出荷方法および均一な移動時間を指定することもありますが、一般的ではありません。

循環ソーシング関連の指定には次のルールが適用されます。

• ローカル・ソース・ルールと物流構成表を使用して循環ソーシング関連を指定できます。グローバル・ソース・ルールは使用できません。

• 双方向循環ソーシング関連を両方向に対して指定する必要があります。そうしないと、循環ソーシング関連は完了しません。

• 3つ以上の組織が関係する循環ソーシング関連の場合は、個々の転送先組織の個々のローカル・ソース・ルールまたは物流構成表（BOD）で循環ソーシング関連を指定する必要があります。

たとえば、R1、R2、R3という3つの組織がある場合は、次の3つのローカル・ソース・ルールを設定する必要があります。

前の例で、R1とR2は循環ソーシング関連を持っています。R2とR3も循環ソーシング関連を持っています。しかし、R1とR3の間には直接の関連がありません。組織R1とR3の間には転送が作成されていません。

3つの組織すべての間に完全な循環関連を作成するには、循環関連にある個々の双方向ペアを最低限1回確立する必要があります。

循環ソース・ルール

計画ロジックでは循環ソース・ルールを考慮します。循環ソース・ルールでは、使い切り優先関連を作成します。つまり、他の場所から追加の供給をソーシングする前に、まず循環関連内のすべての過剰供給がコミットされます。

次の例を考えてみましょう。

R1またはR2で需要が発生した場合は、D2から供給をソーシングする前に、需要が発生していない方の組織にある供給を使い切ります。この動作は、R1とR2の間で在庫を均衡させる効果があります。

循環ソーシングのロジックでは需要の優先度を考慮します。つまり、組織Aと組織Bの間に循環ソーシングが指定されている場合は、優先度のより高い組織Aの需要に割付ける必要がある供給が組織Aから組織Bへの転送に使用されないときにのみ転送が作成されます。計画エンジンは、剰余予定使用可能在庫および循環ソーシング需要を満たすために必要として指定されている剰余存続日数を考慮することによって、需要優先度を尊重します。

剰余予定使用可能在庫、簡単に言えば「剰余」は、安全在庫レベルを超える確定供給と定義されています。

「循環ソーシング剰余日」を参照してください。

循環ソーシング関連を考慮するときは、次のルールを使用します。

• 計画オプションは、特定の計画に対して循環ソーシングを有効または無効にします。デフォルトでは循環ソーシングが有効になります。

• 確定供給のみが考慮されます。確定供給とは、手持在庫、確定計画受入および確定計画オーダーです。

• 循環ソーシング需要に対しては、剰余予定使用可能在庫のみが供給ソースとして考慮されます。

• 循環ソースでの確定供給のみが剰余の計算に使用されます。循環ソースの上流の供給は計算で考慮されません。

「循環ソーシング剰余日」（デフォルト値 = 0）と呼ばれる計画オプションで、循環ソーシング需要向けの供給として剰余を使用するために必要な剰余存続日数を指定します。

「循環ソーシング剰余日」の値を搬送期間以内の日数未満に設定すれば、剰余を循環ソーシング需要向けの供給として利用できます。次回の計画実行までの間に需要が大幅に変化した場合は、直前の文章で説明した動作が望ましいかもしれません。それ以外の場合は、「循環ソーシング剰余日」を搬送計画範囲以上の値に設定して、計画エンジンが循環ソーシング需要向けに(出荷連結で生じた)剰余を使用することを防止します。

3日目の3単位の供給が剰余と見なされます。9日目に需要があるため、6日目に剰余の供給は利用できません。

注意: 「循環ソーシング剰余日」の値は、剰余が使用可能になっている必要のある追加日数を加算するために使用されます。循環ソーシング剰余日 = 0であれば、当日の終わりまでしか剰余が存続する必要はありません。

• ソース・ルール・フォームで指定された循環ソースに対して複数の出荷方法を指定することはできません。ソース・ルールでは、1つの組織を1回しか循環ソースとして指定できません。ソース・ルール・フォームで指定された出荷方法は、その方向のすべての転送に使用されます。出荷方法が空白の場合は、デフォルトの出荷方法が使用されます。

• 循環ソーシングは日次計画バケットでのみ考慮されます。週次計画バケットでは考慮されません。ユーザーが将来の特定の日数にわたって循環ソーシングを必要とする場合は、短期計画範囲内の日次計画バケットの数に最小限その日数を含める必要があります。

• 2つの循環ソーシング需要の優先度が同じ場合、どちらの循環ソーシング需要を先に満たすかは指定できません。

• 循環ソーシングには品目発注モディファイア（固定ロット乗数）が使用されます。

• 計画プロセスは、通常の補充プロセスで需要を満たす前に、可能であれば、必ず在庫を均衡させる方法または循環ソースの在庫を使用する方法を試します。たとえば、中央倉庫から資材を移動しても、異なる地域倉庫間で在庫を均衡させても需要を満たせる場合、計画は、中央倉庫から在庫を移動する方法ではなく、在庫を均衡させる方法を選びます。

• 循環ソーシングは交替と連携します。計画は、他のソース・タイプ（新規購買、移動元および修理場所）から在庫を調達する前に、交替チェーンの剰余を検索します。

需要優先度

サービス計画は、Oracle Advanced Supply Chain Planningで使用されるものと同じ需要優先順位付け方式に従います。「オーダー詳細」のユーザー・インタフェースに需要優先度が表示されます。

乏しい供給を個々の需要タイプに割付ける際の優先度をソース・インスタンスで指定することも、SQLツールを使用して個々の需要タイプの優先度をODSへロードすることもできます。必要に応じて、オンライン計画を開始する前に需要優先度を更新できます。

• 「計画オプション」フォームで「需要優先度ルール・セット」から「ユーザー定義優先度」を選択します。「ユーザー定義優先度」を選択すると、Service Parts Planningは個々の需要に対してユーザーが指定した需要優先度を使用します。

• 受注明細および品目需要予測に優先度を入力できます。これらのフィールドがnullの場合、供給を需要に割付ける際に優先度は使用されません。

需要優先度の詳細は、『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』の「サプライ・チェーン計画の定義」の需要優先度ルールに関する項を参照してください。

リバース・ロジスティクス割当セット

計画による障害品の検索で検索対象となる組織を導出するときは、計画とオーダー納期処理が良品品目用の許可されたソースと障害品品目用の許可されたソースを簡単に識別できるようにソース・ルールのセットを設定する必要があります。修理場所ソース・ルールと返品先ソース・ルールは障害品にのみ適用されます。同様に、移動元ソース・ルールと購買元ソース・ルールは良品の在庫にのみに適用されます。このように、エンジンは部品の状態に応じて適用されるソース・ルールのタイプを判別し、品目に対する有効なソースを推定できます。

たとえば、同じ品目に対して移動元ソース・ルールと返品先ソース・ルールの両方が定義されているとします。品目の障害品在庫を移動する必要がある場合、有効なソースは返品先ソース・ルールに基づいて決定されます。同様に、品目の良品在庫を移動する必要がある場合、有効なソースは移動元ソース・ルールに基づいて決定されます。基本的に、障害品部品と良品部品の区別はソース・ルールを通じて行われます。

スペア部品予測の選択肢

• （1）補充組織からのアウトバウンド出荷に基づいてローカル返品予測を生成する方法を選択できます（次の図を参照してください）。この予測方法では、（3）現場から返品され、入荷する超過部品を除外します。

• （2）フィールド・サービス・ゾーン用のグローバル予測を生成した後、グローバル予測割当ルールを使用して補充組織間で予測を適切に分配します。グローバル予測は需要と返品の両方に対して行われます。

スペア部品の需要については、予測配分セットが（グローバル予測の設計に従って）技術者組織から使用量予測を取得し、補充組織に需要を割り当てます。

返品予測はフィールド・サービス組織または実際のフィールド・サービス返品が発生する組織用に生成されます。この予測は返品ネットワークに適切に実装されます。サプライ・チェーンはフィールド・サービス組織用の計画を作成しないため、フィールド・サービス組織用に生成された返品予測は返品品目の移動先となる組織に実装する必要があります。この返品予測の供給は、返品として供給に算入されます。

ソース・ルール「戻る」の割当て

ゾーンの需要を組織固有の需要に配分するときにソース・ルールが適切に考慮されるように、返品先ソース・ルールをグローバル予測割当セットに割り当てます。

組織を指定できるのは返品先ソース・ルールのみであるため、ユーザー・インタフェース検証は値リストに組み込まれています。ランク1の返品先ソース・ルールが使用されます。ランク1内のすべてのソーシング分割が適用されます。ランク2以上は選択できません。

返品先ソース・ルールは障害品を修理組織へ移動するときにも使用されます。このように、「返品先」はグローバル・コンテキストのみでなく、障害品を組織間で移動するコンテキストでも使用されます。したがって、返品先ソーシング・タイプでは、全組織（グローバル）レベルのソース・ルールと組織（ローカル）レベルのソース・ルールの両方がサポートされます。

これは宛先専用フォームであり、割当セットに割当て可能です。

たとえば、ゾーン1の需要計画によって生成された品目Aのグローバル返品予測によれば、数量は1月10日が100単位、1月12日が200単位です。

返品先グローバル・ソース・ルールは、前述のグローバル予測を組織M1とM2に均等に割り当てるよう定義しています。

このソース・ルールをゾーン1に割り当てると、ソース・ルールに従って返品予測数量を2つの組織M1とM2に均等に配分することによって、オーダー・タイプ「返品」が計画で生成されます。

ソース・ルール「修理場所」の割当て

ソース・ルール「修理場所」では、仕入先または組織をその部品の修理組織として指定します。修理場所ソース・ルールは社内修理および社外修理の両方に対して有効です。ソーシングがVCP宛先インスタンスでのみ有効になるため、このソース・ルールは宛先インスタンスで定義されます。

修理場所ソーシングは修理組織に対して定義されます。転送ソース・ルールを使用して、障害品を修理組織へ移動し、良品資材を修理組織から外部へ移動します。この操作は社内修理組織と外部修理組織の両方に対して有効です。

たとえば、次のサービス・サプライ・チェーンについて考えてみましょう。

中央スペア倉庫では、社外修理デポと社内修理デポの両方に対する修理場所ソーシングを持っています。次の表に示すようにソース・ルールが定義されています。

さらに、次のソース・ルールが社内修理組織と社外修理組織で定義されています。

障害品を中央倉庫から移動するために、障害品の移動に関する転送ルールが定義され、割当セットに割り当てられます。

障害品が中央倉庫に返品される場合は、障害品を修理組織へ移動するための移動元ソース・ルールも必要です。これらのソース・ルールは割当セットで「条件」が「障害品」に設定されています。

このソース・ルールを適切な割当レベルで中央スペア倉庫と修理組織に割り当てることができます。そうすれば、計画エンジンによって適切な推奨事項が生成されます。推奨事項には次のものが含まれます。

• プッシュまたは事前配置のシナリオを持つ修理仕入先の場合

  • 修理仕入先への発注

• プルまたは修理返品のシナリオを持つ修理仕入先の場合

  • 修理仕入先への発注

  • 資材を修理仕入先へ移動するための移動オーダーまたは社内受注

• 修理デポの場合

  • 資材を修理デポへ移動するための、内部修理オーダとして呼び出される転送オーダー

  • 修理デポでの修理作業指示

  • 修理デポから要求元組織への転送オーダー

修理場所ソーシングは、「ソース・ルール/BOD」フォームでの定義と検証という点で、製造場所ソース・ルールと似ています。

組織が修理仕入先組織である場合は、この組織に付随する仕入先および仕入先サイトが表示されます。仕入先と仕入先サイトを直接入力することはできません。

修理場所ソース・ルール対製造場所ソース・ルール

修理場所ソーシングはサービス・サプライ・チェーン計画でのみ適用されます。サービス・サプライ・チェーン計画では、製造場所ソーシングを使用しないため、サービス計画に割り当てられたソース・ルールの製造場所ソース・ルール・エントリを無視します。同様に、ASCP計画およびDRP計画では修理場所ソース・ルールを無視します。

ソース・ルールおよびランク

サービス・サプライ・チェーンでは、特定の需要を満たすときの計画作業環境が次のようになります。

Service Parts Planningは、特定の品目に対して、まず手持在庫と計画受入をサプライ・チェーン全体で検索し、次に（ランクに基づいて）修理ソース・ルールおよび購買ソース・ルールを使用することによって需要を満たそうとします。特定のソース・タイプに複数のソースがある場合、計画は、需要側ノードからの距離を使用し、同じ距離のソースが複数ある場合はランクを使用します。

たとえば、組織M1に2つの修理場所ソースが存在するとします。Service Parts Planningは、ランクの低いソースを使用する前に、ランクの高いソースを修理場所として使用します。

2番目の例では、1つはヨーロッパ、もう1つは米国に、2つの中央倉庫があるとします。両方の倉庫が修理場所ソースを持っています。米国で需要が発生した場合、計画は、ヨーロッパの修理場所ソースを使用する前に、まず米国の修理場所ソースを使用します。

ソース・ルールと交替品目属性

品目が多数あり、個々の品目の品目属性を変更できるので、どの品目の定義がサプライ・チェーン計画で使用されるかを理解することが重要です。

計画エンジンは品目レベルのソース・ルールの値を考慮します。新規品目を交替チェーンに導入するたびにソース・ルールを再定義する必要はありません。交替チェーン全体に対してソース・ルールを1つだけ設定できます。チェーン内の品目の1つが異なるソース・ルールを持っている場合は、例外として、品目レベルのソース・ルールを設定します。個別のソース・ルールは全般的なソース・ルールより優先されます。

品目によってソース・ルールが変わるときのエンジンの動作または検索パターンを説明する例を次に示します。

• A -> B （品目Bが品目Aに取って代わります）

• Aは組織1（主ソース）と組織2（第2ソース）からソーシングできます

• Bは組織2（主ソース）と組織3（第2ソース）からソーシングできます

この例では、エンジンは次の順番で良品在庫を検索します。

1. 組織1のA

2. 組織2のB

3. 組織2のA

4. 組織3のB

まず交替チェーン内の主ソースで検索が行われます。次に、交替チェーン全体で第2ソースの検索が行われます。

同様に、計画エンジンは品目固有の属性を考慮します。つまり、交替チェーン内のどの品目が修理、移動または購買されるかに応じて、その品目の固有の属性が考慮されます。

注意: 新規購買オーダーは最新改訂に対してのみ生成できます。したがって、最上位改訂の視点からは、常に新規購買関連品目の属性が適用できます。

代替出荷方法

代替出荷方法とともにソース・ルールを定義し、それらのランクを指定することによって、代替出荷方法を使用するよう指定できます。代替ソースが有効になっている場合は、代替ソースを使用することによって、予定通りに、または需要日になるべく近い期日に需要が満たされると計画が判断すれば、代替出荷方法を持つ低ランクの代替ソースが考慮されます。

注意: Service Parts Planningは、まず既存の供給、次に修理、最後に新規購買を使用するという固有のソーシング・ロジックとランク付けに従うため、代替出荷方法は、特定のソース（現行供給、修理または新規購買）からの供給を考慮するときに検討の対象になります。

たとえば、既存の供給を組織1から組織2へ、陸上輸送を使用して15日間で、または航空輸送を使用して2日間で移動できるとします。コストが低いため、陸路で部品を出荷する方法が好まれます。組織1から組織2への移動に対して2つのソース・ルール・エントリを定義し、各行で2つの出荷方法を指定します。計画は陸路15日のリード・タイムで部品を移動しようとしますが、優先オーダーの場合は空路の出荷方法を推奨します。

有効な制約

Service Parts Planningでは、次の制約を考慮します。

• 品目リード・タイム制約: この制約では次のリード・タイム要素を考慮します。

  • 修理組織への障害品の転送

  • 修理工程

  • 良品部品の倉庫への転送と受入

• 資材制約: サプライ・チェーン内の障害品部品の数量が（返品と修理歩留を考慮する点で）修理に対する制約として作用します。

• 修理に関する仕入先の能力: SPP計画は、修理作業の実行に関する外部仕入先の能力に制約されません。ただし、SPPは、修理作業の能力を読取り、作業ロードが能力を超える場合には例外メッセージを生成します。

• 新規購買に関する仕入先の生産能力: 新規購買仕入先の生産能力は承認済仕入先リスト（ASL）の「計画」タブで定義できます。ただし、SPPが新規購買仕入先の生産能力を直接考慮することはありません。供給能力が不足している場合は、SPPがこの生産能力に違反することがあります。ただし、SPPは、仕入先生産能力制約の違反を知らせる例外メッセージを生成します。

制約の有効化または無効化

Service Parts Planningの計画オプションでは、リード・タイム制約を有効化または無効化できます。制約が有効化されている場合でも、計画はその制約に違反し、その結果、例外メッセージを生成することがあります。

制約の施行が無効になっている場合

計画はリード・タイム制約を守って、予定通りに需要を満たそうとします。生産能力が不十分な場合、計画は、予定通りに需要を満たすための必要性に応じて、リード・タイムを圧縮するか、生産能力に過負荷をかけます。

リード・タイム圧縮ロジックは次のように働きます。

• サプライ・チェーン最適化により、圧縮率が最小限になるサプライ・チェーン・パスが選択されます。

• サプライ・チェーン・パス内では、システム日付に最も近い時期に圧縮が行われます。同じ条件のサプライ・チェーン・パスが複数ある場合は、次の順に選択します。

  1. 修理ソース

  2. 在庫再残高計算ソース

  3. 新規購買ソース

制約の施行が有効になっている場合

計画は、リード・タイム制約を施行して、納期までに需要を満たそうとします。納期までに需要を満たせない場合、計画は、需要を満たせるようになるまで供給日を将来のバケットへ先送りします。

• 現場組織での受注およびアウトバウンド出荷の場合

  • 需要タイプが受注需要である場合、計画は需要納期までに需要を満たそうとします。

  • それが不可能な場合、計画は納期後の最も早い期日に需要を満たそうとします。

  • 計画が需要をまったく満たせない場合は、計画終了日（計画範囲の最後）に需要が満たされると想定します。

    最終受入期限日は表示専用列です。エンジンは「最終受入期限日後の遅延日数」と呼ばれる例外の属性を持つ遅延補充の例外メッセージを生成します。

• 予測の場合

  • プロファイル・オプション「MSO: 予測失効前の最大許容遅延日数」を過ぎると予測は失効します。

  • 計画は、需要日または需要日以降のなるべく早い期日までに、すべての失効していない需要を満たそうとします。最悪の場合は、計画範囲の最後に需要が満たされると想定します。

    計画は、需要を満たす際の期限としてバケット終了日を使用します。

コスト・ベースの最適化

Service Parts Planningはコスト・ベースの最適化計画モードをサポートしています。このモードでは、最もコスト効果の高い手段に基づいて供給を選択します。

最適化が有効になっていると、計画は通常の計画ソース選択ロジック（計画受入、修理、新規購買の順）に従わず、最もコスト効果の高い解決策を選択します。原価要素を正確に設定し、それをうまく管理することは、きわめて重要です。不正確な原価は、多くの場合、最適未満の解決策をもたらします。

「品目属性一括保守」と「計画オプション」タブを最適化に使用する方法の詳細は、次を参照してください。

• 品目シミュレーション・セット(一括保守)

• 「サービス・サプライ・チェーン計画」オプション

• 「最適化」タブ

原価の最適化の有効化

原価の最適化を有効にするには

1. 「品目属性一括保守」ウィンドウを使用して修理原価を設定するか、グローバル・プロファイル・オプション「MSC: 標準原価の比率としての修理原価」を使用します。

2. 「計画オプション」フォームの「最適化」タブで「最適化」チェック・ボックスをオンにします。

3. （オプション）「納期搬送」、「利益」および「在庫回転率目標加重」を調整します。

   例a:

   • すべてのリード・タイムより長い納期の需要が中央倉庫で発生します。

   • 障害品を障害品倉庫から修理施設へ転送するのに要する転送原価: 1単位当たり5

   • 修理原価: 1単位当たり10

   • 良品部品を中央倉庫へ転送するのに要する転送原価: 1単位当たり2

   • 購買原価: 1単位当たり15

     この場合は、障害品単位の移動と修理に要する原価合計（17）より新規単位の購買原価（15）の方が低いため、新規購買仕入先を使用して需要を満たします。

   例b:

   このシナリオでは、原価は前の例と同じですが、修理リード・タイムより長く、購買リード・タイムより短い納期の需要が発生しています。遅延供給のペナルティは1日当たり5です。つまり、新規購買仕入先は納期に間に合うように納品できません。

   この場合は、修理施設を使用して需要を満たします。そのときの原価（17）は新規購買プラス遅延ペナルティの費用より低くなります。 (15 + 5 = 20).

予約のサポート

修理オーダーのマルチレベル予約モデルでは、社内修理オーダーおよび社外修理オーダーとのリンクを保ちます。

社内修理

顧客返品: この修理プログラムでは、修理のために送付された製品と（シリアル番号が）同じ製品を顧客へ戻すよう要求します。修理組織では、デポ修理が作業指示に対する受注用の予約エントリを作成します。計画は受注を保持し、作業指示へ受注をペグします。

社外修理

修理の発注は、（障害品を修理組織へ移動し、良品部品を中央倉庫へ移動するための）転送オーダーに連結され、修理組織における修理作業指示にも連結されます。

オーダー・モディファイアおよびリバース・サプライ・チェーン

SPPは、計画新規購買オーダーについてのみオーダー・モディファイアを考慮します。新規購買のオーダー・モディファイアはASLレベルおよび品目レベルでサポートされます。SPPでは、通常、品目が新規購買タイプおよび修理場所タイプのソーシングを持ちます。その場合、オーダー・モディファイアは品目レベルで設定され、新規計画オーダーでは考慮されますが、修理計画オーダーでは考慮されません。

（サプライ・チェーン最適化ソルバーの後で行われる）後処理では、品目のオーダー・モディファイア数量に基づいて新規購買推奨を調整した後、オーダー数量の調整の結果不要になった他の新規購買推奨を除去します。これは新規購買品目のレベルでのみ行われる資材バッファ修正です。他のレベルまたは品目では修正は行われません。

このように、修理供給を調整する前に、まず将来のバケットの新規購買が調整されるように調整が行われます。仕入先生産能力と仕入先生産能力違反を指摘する例外が表示されます。

SPPエンジンは仕入先生産能力の制約を考慮しません。つまり、SPPが生産能力を理由として主新規購買仕入先から代替新規購買仕入先へのオフ・ロードを推奨することはありません。理由がリード・タイムであれば、SPPは代替仕入先へのオフ・ロードを推奨できます。

ユーザーは仕入先生産能力違反例外を検討し、必要に応じて代替新規購買仕入先へのオフ・ロードを手動で行う必要があります。

新規部品番号としての再生部品の設定

一部の組織では、新規部品番号を作成することによって、新規サービス部品を再生部品、つまり修理済部品と区別します。このドキュメントおよびSpares Managementで説明しているサービス計画ソリューションでは、新規部品と修理済部品の間に違いはないと見なします。

ソリューションを使用して、修理済部品に別の部品番号を割り当てる処理に対応するには

1. 修理済部品、つまり再生部品を交替部品として設定し、それを交替チェーンに挿入します。その部品を最新改訂との双方向関連として定義します。

   A ->A1 ->ARefurb <- -> A2

2. 再生部品ARefurbを定義した後、再生部品を新規部品として交替チェーンに導入します。すべての改訂の修理対象部品としてARefurbを定義します。

   

   3つの主要なビジネス・シナリオが存在します。

   • 新規部品を購買する前に、必ず再生部品を使い切りたいという要望があります。

     新規部品の需要を予測し、新規部品の社内受注需要を作成します。再生部品（ARefurb）をチェーン内の最上位改訂部品（A2）との双方向関連として設定します。計画は、必ず、交替部品からチェーン内の最上位部品への順に資材を検索するため、A2を使用する前にARefurbの供給を使い切ります。また、計画は、追加受注を作成するときに、すべての障害品を再生部品（ARefurb）に変換する修理オーダーを生成し、最上位改訂（A2）の新規購買を指示する前に、その供給を使用します。

   • 技術者が再生部品と新規購買部品の両方を持ち歩き、再生部品を使用するか新規購買部品を使用するかを状況に応じて決定する必要があります。技術者が、通常、再生部品と新規部品の両方に対してMin-Max（オーダー・ポリシー）を設定する点を除いて、これは最初のシナリオと同じプロセスです。

   • 計画エンジンが、最終顧客に基づいて、再生部品が使用可能かどうかを動的に判断します。たとえば、顧客XYZとの契約の条件により、再生部品をサービスに使用できないことがあります。交替はグローバル定義です。したがって、このリリースは、顧客ベースの代替をサポートしていません。

   再生部品を新規部品番号として設定することによって次の機能が得られます。

   • 計画は、新規部品の供給を推奨する前に、修理済部品の既存の供給を考慮します。

   • 技術者は新規部品または修理済部品のどちらでも要求できます。

再発注点ベースの計画

概要

再発注点ベースの計画はサービス部品の補充計画で広く採用されている方法です。この方法では、需要予測とリード・タイムを使用して、新規発注を行う時期およびオーダーの数量を決定します。需要予測とリード・タイムに基づいて安全在庫値を計算します。最適なオーダー・サイズを決定する経済的オーダー数量は、購買原価と在庫保管費に基づいて決まります。

Oracle Service Parts Planningは、現在、再発注点ベースの計画をサポートしています。この種の計画を使用できるように、SPPは、品目の需要パターン、リード・タイムおよび原価に基づいて安全在庫とEOQを計算できます。さらに、計画担当は、システムが計算した値をユーザー定義値で上書きできます。

再発注点ベースの計画を構成する手順については、「ソースおよび宛先インスタンス・データの設定」を参照してください。

次の図は、在庫が安全在庫レベルを常に上回るように設計された代表的な使用と補充のサイクルを示しています。

通常の需要に対する安全在庫値の計算

通常の需要パターンの場合は、一定期間内の需要数量を正規分布で説明します。次に例を挙げます。

MADは実際の需要に基づいた予測履歴の平均絶対偏差です。この方法では、予測と実際の需要を比較して予測の精度を判定し、それに基づいて在庫欠品を防止するために必要な安全在庫の数量を求めます。過去の予測がきわめて正確だった場合は、少量の在庫しか必要とされません。

平均絶対偏差の計算は次の式を使用して行われます。

nはタイムバケットの数を表します。

このMAD値に基づいて、安全在庫レベルを次の式で求めます。

安全在庫 = Z x (1.25 x MAD) x sqrt(LeadTime)

Zは、ユーザーが指定したサービス・レベルに対応する正規分布確率を表す値です。プランナはMADの計算で使用されるサービス・レベルをシミュレーション・セットで設定する必要があります。sqrt（LeadTime）係数は、品目のリード・タイム中の需要の変動を表します。

注意:

• 現在のOracle Inventoryの計算では、作業日数の異なるバケットに対して異なる安全在庫値が導かれます。この方法に基づいた安全在庫数量は、これらのすべての数量の（バケット当たりの）平均値です。

• 計画品目は需要側組織が仕入先から直接調達するため、この計算では購買リード・タイムのみを考慮すれば済みます。

• 計算された偏差と経済的オーダー数量では、組織におけるローカル予測のみを考慮しています。SSまたはEOQの計算では、組織に配分されたグローバル予測は考慮されません。

• 通常の需要の場合、EBS予測は安全在庫値の計算で考慮されません。

断続的実行需要に対する安全在庫値の計算

断続的実行需要は、需要到着が散発的で、タイムバケット内に需要がないことが多い需要到着パターンを説明するために使用されます。このパターンは、通常、ポアソン過程によってモデル化されます。

断続的実行需要の場合、計画エンジンはターゲット在庫レベルを決定し、それに基づいて安全在庫レベルを計算します。

ターゲット在庫レベルは次のように計算されます。

ただし

• Sはターゲット在庫レベル

• uは経済的オーダー数量に等しいオーダー数量（次を参照）

• Aは平均需要到着率、

• Lはリード・タイム

需要到着率はSPPでの予測に基づいて決定します（年率換算）。

リード・タイムは収集された品目属性から取得できるか、IMMを介して設定できます。

計算されたターゲット在庫レベルに基づいて、安全在庫レベルを次の式で求めます。

安全在庫SS = ターゲット在庫レベル – リード・タイム中の需要 = S – (A uL)

安全在庫> = ターゲット・サービス・レベルの安全在庫になるように、計算された安全在庫値を四捨五入します。

交替チェーンに対する安全在庫の計算

交替チェーンの一部である品目の予測を生成するときは、チェーン全体の履歴を考慮します。通常は、品目の様々な改訂に対して同じ予測ルールが使用され、需要パターンも同様と見なされます。

平均絶対偏差: 平均絶対偏差（MAD）を計算するときは、交替チェーン全体の履歴と予測を計算に入れて、チェーンに対する1つのMAD値を求めます。この計算はすべての改訂に適用されます。

需要到着率: 需要到着率を計算するときも、計画エンジンは、1年間にわたる（つまり年換算された）交替チェーン全体の需要を考慮して、チェーンの需要到着率を表す1つの値を求めます。

サービス・レベル: 交替チェーンの別々の改訂に対して同じサービス・レベルが設定されることはよくあります。しかし、この計算ではそれが想定されず、改訂の安全在庫レベルを計算するときは、改訂ごとに異なるサービス・レベルを考慮します。

リード・タイム: 同様に、複数の改訂が似通ったリード・タイムを持っていることはよくありますが、改訂ごとに設定された値が個別に考慮されます。

交替品有効日

交替品有効日の場合は、（廃止になる可能性が最も低い）最上位改訂の安全在庫を保有することが賢明です。したがって、エンジンは、最上位改訂に対してのみ安全在庫ターゲットを考慮します。

この有効日の設定をIMMに反映させることはできないことに注意してください。IMMは1つしか安全在庫値を持っていません。ただし、エンジンは有効日を考慮し、有効日の設定に従って安全在庫を設定します。

次の例はこの動作を示しています。

例: 交替品有効日が次のように設定されています。

1月10以降にA > B

Aの安全在庫 = 40、Bの安全在庫 = 50 (IMMで設定)

この場合、IMMとMSC_SYSTEM_ITEMSは次のようになります。

エンジンはこれら2つの情報を読取り、安全在庫ターゲットを次のように設定します。

供給を計画するとき、SPPは、安全在庫ターゲットを満たす「一次」全体の供給を考慮します（ユーザーがプロファイル「MSC: 品目安全在庫値レベル」を「一次」に設定しているとします）。

経済的オーダー数量の計算

経済的オーダー数量（EOQ）は在庫の取得と保管の両方に要する費用を最小限に抑えるために計算される固定オーダー数量です。次のように定義されています。

ただし、

• Q * = 経済的オーダー数量

• D = 製品の年間需要数量

• C = オーダー当たりの固定原価

• H = 単位当たりの年間在庫保管費

製品の年間需要数量は生成された予測に基づいて計算されます。予測期間が1年未満の場合は、年換算されます。この値は、SPPで生成された予測または使用されている予測に基づいて計算できます。

オーダー当たりの固定原価は品目に対するオーダーを発行する費用です。これはオーダーを発行するための取引原価であり、オーダーする品目の数量やオーダーの頻度とは関係ありません。オーダー原価は品目マスターから取得できます。この属性の元の（収集された）値を示すIMMの「品目-組織」タブでもオーダー原価を取得できます。

単位当たりの年間在庫保管費は、品目マスターで設定された原価から導かれ、在庫保管費のプロファイル・オプションに基づいて決まります。

在庫保管期間が通常より短くなるため、大量のオーダーの在庫を保管するときの費用は通常のオーダーより小さくなります。そのため、EOQは需要の増大とともに増加します。EOQは、オーダーを準備する費用が増大するときにも増加します。このように設定されているのは、オーダーの数が多すぎるために必要以上の頻度でこのコストが発生することを避けるためです。

一方、過剰な在庫を保管するには余計な費用がかかるため、在庫保管費が高いほど、EOQは減少します。

注意: EOQを計算するときの入力値に誤りがあると、エンジンは固定オーダー数量を（エラーを示す）-1に設定します。エンジンは計画中にこの値をスキップします。

交替チェーンに対するEOQの計算

需要: 経済的オーダー数量を計算するときは、交替チェーン全体の需要を考慮します。SPPで使用されている予測が年間需要の計算で考慮されている場合は、チェーン内のすべての改訂の予測および需要を考慮する必要があります。インライン予測の場合は、いずれの場合も、最上位改訂が予測の対象になります。

年間需要: この値は、品目の様々な改訂の予測を合計した値に基づいて計算されます（年換算）。

オーダー原価、在庫保管費: 様々な改訂のオーダー原価と在庫保管費は、同一と言わないまでも、似通っています。オーダー原価と在庫保管費は品目の改訂ごとに考慮されます。

このように、SPPは品目の改訂ごとにEOQの値を計算し、その値をIMMで設定します。ユーザーは、様々な改訂に対してEOQ計算が一様にオンまたはオフになっていることを確認する必要があります。

例:

事例1:

年間使用量は需要履歴から取得でき、在庫保管費は標準原価の比率として定義されています。オーダー原価はユーザーによって品目属性として設定されます。次に示す最初の例では、2つの交替品目のEOQ計算を行っています。

事例2:

次の交替チェーンを考えてみましょう。

Item_5 -> Item_6 <-> Item_7

需要は次のとおりです。

上の表に基づいて計算すると、交替の年間需要は最大3,800単位になります。

オーダー原価は250ドルで、単位当たりの年間在庫保管費は5ドルです（ここでは、これらの値がすべての改訂について同じであるとします）。

これらの値に基づいて、EOQはsqrt (2 x 3800 x 250 / 5) = 617単位と計算されます。個々の改訂がそれぞれ異なるオーダー原価と在庫保管費を持っている場合は、それに応じてEOQ値が変わります。

EOQが3つの改訂すべての「固定発注数量」列に更新されると、この値は変化します。それ以降、SPPは、計画を作成するときに交替を考慮します。したがって、

• 09年3月に計画オーダーを作成する必要がある場合は、617単位のItem_6に対するオーダーを作成するのに対して、

• 09年12月に計画オーダーを作成する場合は、同じ個数のItem_7に対するオーダーを作成します。

供給割付ルールの定義

計画エンジンは、新規に受注した部品がまだ納品されておりず、受注した部品の総数が現在組織で使用できる供給を上回っている場合に、通常、供給割付ルールを使用して、制約付き供給に対して「フェア・シェア」を適用します。具体的に言えば、次の3つの条件が満たされている必要があります。

• 2つ以上の競合する需要が同じ需要優先度を持っている

• 競合する需要のうち少なくとも1つが組織間の転送である

• 現在の割付バケット内に供給不足が存在する

供給割付ルールは、異なる組織からの競合する需要の間で制約付き供給がフェア・シェアされる方法を決定します。次の2段階にわたって、これらのルールを作成し、有効化します。

1. ルール自体を作成し、名前を付けます。

2. ルールを特定のインスタンス/組織および品目/カテゴリに関連付けます。

次の手順に従って新規の供給割付ルールを作成します。

1. 「サービス部品計画」→「ソーシング」→「供給割付ルール」へ移動します。

2. この新規供給割付ルールの名前と説明を入力します。

3. このルールの有効日付範囲を入力します。少なくとも開始日を入力する必要があります。終了日を空白にした場合、ルールは無期限に有効になります。

4. 「組織」セクションで、「組織」列に少なくとも1つの組織を入力する必要があります。ソース組織と需要組織の両方を入力できます。これらは供給割付ルールが考慮の対象とする組織です。

5. 個々の需要組織の優先度を設定します。値が小さいほど優先度が高くなります。1が最高優先度です。組織優先度は、異なる組織の同じランクを持つ競合する需要間のタイブレークに使用します。

6. 「ファイル」→「保存」を選択します。

注意: SPP計画では、計画オプションの「メイン」タブ・ページで指定された需要優先度ルールに基づいて需要優先度を計算します。

注意: 供給割付ルールは、修理を待機している障害品部品には適用されません。

品目と組織への供給割付ルールの割当て

供給割付ルールを作成したら、ルールを有効にするために割り当てる必要があります。ルールは、組織全体、組織内の品目のカテゴリ、または組織内の個別の品目に割り当てることができます。

注意: 供給割付ルールは、組織のみに割り当てられ、顧客サイトには割り当てられません。

次の手順に従って供給割付ルールを割り当てます。

1. 「ソーシング割当セット」ページへ移動します（「ソーシング」→「ソース・ルールの割当」）。

2. 「供給割付」タブをクリックします。

3. 最上部で、割当セットの名前と説明を入力します。

4. 最初の行を選択します。

5. 「割当先」リストの品目を選択します。

   • インスタンス-組織: 組織内のすべての需要が含まれます。

   • カテゴリ-インスタンス-組織: 組織内の品目に対する需要のみが含まれます。

   • 品目-インスタンス-組織: 特定の品目に対する需要のみが含まれます。

6. 選択した割当先に応じて、インスタンス/組織または品目/カテゴリに対応する値を入力します。

7. すでに作成されている供給割付ルールの名前を選択または入力します。

8. 他の組織、カテゴリまたは品目のルールを含める必要がある場合は、行を追加します。

9. 「ファイル保存」と入力して、割当セットを保存します。

注意: 次の項で説明するように、供給割付に使用されるタイムバケットのサイズは計画オプションで設定されます。

デフォルト割付用計画オプションの設定

注意: 他の計画オプションの日付と同様に、プロファイル「MSC: バケット用カレンダ参照」がnullの場合は、計画を所有する組織に属するカレンダがバケットの設定に使用されます。ただし、このプロファイルが有効なカレンダを参照している場合は、そのカレンダがバケットの設定に使用されます。

1. 「計画オプション」へ移動します.

2. 「総計」タブを選択します。

3. 「割付」セクションには、供給割付のデフォルトのタイムバケットを管理するためのフィールドがあります。最初のフィールドは「期間割付バケット」チェック・ボックスです。このチェック・ボックスがオンになっていると、割付バケットは計画カレンダに基づく固定期間になります（このチェック・ボックスがオンになっていると、「日次割付バケット」と「総割付バケット当り週」がグレイアウトされることにも注意してください）。

4. 「日次割付バケット」フィールドは日次バケットの数を決定します。たとえば、この値が30に設定されていると、（計画開始日から）30日間にわたって、フェア・シェア割付処理が毎日実行され、適切な数の品目が転送用としてマークされます。

   注意: 日次割付バケットは、前の項で説明した「計画オプション」→「総計」ページで指定された日次バケットの数以下にする必要があります。

5. 総割付バケット当り週は、総割付バケット内の週の数を決定します。これらのバケットは日次割付バケットが完了した後に有効になります。この日付は、「総割付バケット開始日」フィールドに表示されます（表示専用）。

   注意: 総割付バケットの設定によって計画範囲が拡大することはありません。

フェア・シェア割付

フェア・シェア割付は供給割付ルールによって定義されるアルゴリズムで、競合するすべての需要を満たすのに十分な在庫を供給組織が持っていないときに有効になります。このルール（「供給割付ルールの定義」の項を参照）は、考慮の対象となる組織およびその組織の相対的優先度を決定します。ルールを定義した後、そのルールを計画インスタンス内の特定の品目、品目のカテゴリまたは組織に割り当てます。

フェア・シェア割付によって使用されるタイムバケットは「計画オプション」の「総計」タブで定義されます。

供給割付ルールを割り当てると、指定された割付方法に従ってフェア・シェア割付が自動的に供給組織の在庫から1つ以上の需要組織へ品目を転送します。最初に使用できるアルゴリズムは現行需要比率に限られます。

現行需要比率は、組織が要求している数量の比率に従って需要を満たすフェア・シェア割付方法です。たとえば、組織1が毎月100単位を要求し、組織2が毎月200単位を要求している場合、（両方の需要が同じ優先度を持っているとすれば）組織2が組織1の2倍の需要を持っているため、2倍の数の品目を受け取ります。150単位が使用できれば、組織2には100単位、組織1には50単位が配分されます。

フェア・シェア割付処理では、交替チェーンを考慮します。複数の製品改訂が存在する場合、アルゴリズムは最下位改訂から開始して、有効になっているルールに従って需要を満たします。次に、アルゴリズムは残りの需要を再計算し、その値に基づいて次の改訂に割付けます。たとえば、交替チェーン内に一方向関連を持つ改訂Aと改訂Bという2つの改訂があるとします。Aに対する100単位の需要とBに対する100単位の需要がありますが、供給倉庫には現在、Aが50単位、Bが60単位しかありません。次の表は、これらの単位がペギング・ルール、交替ルールおよび現行需要比率に基づいてどのように割付けられるかを示しています。

ステップ2の残りの需要を見ると、需要Bと需要Aの比率が2:1になっています。したがって、ステップ3では、使用可能な60単位のBがその比率で割付けられ、20単位が需要Aに、40単位が需要Bに配分されます。

当初の制約なしの需要と、その需要に対するフェア・シェア割付がどのように行われるかは、「需要/供給分析」ウィンドウ（「メニュー」→「ツール」→「需要/供給分析」）に表示されます。この行については、「計画の作業」の「需要/供給分析」ワークシートで詳しく説明します。

安全在庫需要への割付

SPPは、複数の組織からの競合する安全在庫需要への割付で少し異なるロジックを使用します。ソース組織への新規供給がなく、使用可能な供給をソースとすべての下流組織でフェア・シェアするようフェア・シェア・ルールが指示している場合は、通常のフェア・シェア・ロジックに従うと、ソース組織に割付けられた供給が、次のバケットで（安全在庫需要がまだあるため）さらに下流の組織に割付けられる結果を招くことがあります。そうなると、下流の組織はフェア・シェア以上の供給を受けます。

このシナリオを回避するために、SPPは、安全在庫需要への割付けを行うとき、期間ごとにソース組織で供給を一部またはすべて「予約」します。予約される数量は、（a）前のバケットで割付けられた数量と（b）ソース組織における安全在庫需要の比率（%）の変化に応じて決まります。残りの供給のみを競合する安全在庫需要への割付に使用できます（注意: 最初のバケットでは、それより前のバケットがないため、この予約済数量は0です）。

注意: MRP計画比率安全在庫は、需要パターンに基づいて動的に変化するため、安全在庫需要間のフェア・シェアでは考慮されません。

S0がD1とD2に分配する場合を考えてみましょう。3つの組織すべての安全在庫レベルは100単位です。D1またはD2に手持在庫はなく、S0には120単位があります。最初のバケットで、40単位がS0の安全在庫として割付けられ、40単位がD1とD2に出荷されます。

次の割付バケットで入庫する新規供給はないとします。この場合、安全在庫所要量が変わらなければ、S0の40単位は「予約」され、それ以上の割付は行われません。

S0で新規供給の入庫があった場合、その供給はオープン安全在庫需要数量の比率（60:60:60）に従ってフェア・シェアされます。

たとえば、S0の安全在庫所要量が100から10へ減少した場合、S0で予約される数量は40 * (10 / 100) = 4単位になります。残りの36単位はD1とD2に割付けられます。

Copyright © 2010, Oracle and/or its affiliates.All rights reserved.