オーダーの改善がプランニング結果に与える影響の例
たとえば、同じ組織から調達された同じ品目に対して3つのオーダーを計画するとします。 計画前後に関連する販売オーダー属性をチャート・アウトします。 2つの計画シナリオを検討: 1つ目は、3つすべてのオーダーに対してプル・イン使用可能の値がはいで、2つ目は1つのオーダーの改善を考慮できないようにします。
この表は、プランニングに関連する属性値を示しています。
|
オーダー番号 |
要求日 |
要求数量 |
予定日 |
プル・イン使用可能 |
|---|---|---|---|---|
|
オーダー 1 |
01/04/2020 |
10 |
01/15/2020 |
Yes |
|
オーダー 2 |
01/06/2020 |
4 |
01/15/2020 |
Yes |
|
オーダー 3 |
01/12/2020 |
6 |
01/15/2020 |
Yes |
供給有効数量情報
-
01/11/2020に10ユニット
-
01/15/2020に10ユニット
計画実行のキー設定
-
単純需要優先度ルールREQDATEを選択します。このルールでは、リクエスト日までに需要に優先順位を付けます。 最も早いリクエスト日のオーダーの優先度が高くなります。
-
プル・イン有効値は、3つすべてのオーダーに対してYesです。
すべてのオーダーの改善を考慮した計画結果
計画が実行された。 表には、計算された優先度値および計画日も含まれるようになりました。
|
オーダー番号 |
計算済優先度 |
要求日 |
要求数量 |
予定日 |
計画日 |
プル・イン使用可能 |
|---|---|---|---|---|---|---|
|
オーダー 1 |
10 |
01/04/2020 |
10 |
01/15/2020 |
01/11/2020 |
Yes |
|
オーダー 2 |
20 |
01/06/2020 |
4 |
01/15/2020 |
01/15/2020 |
Yes |
|
オーダー 3 |
30 |
01/12/2020 |
6 |
01/15/2020 |
01/15/2020 |
Yes |
オーダーは、リクエスト日に基づいて優先順位付けされます。 オーダー1の推測は予定日より後に改善されました。 これは、オーダー1からのリクエストを満たすために、01/11に10単位の供給が使用可能になったためです。 01/15にはさらに10ユニットの供給が可能で、そのうち4ユニットはオーダー2に、6ユニットはオーダー3に、リクエストどおりにオーダー3に割り当てることができます。
次に、オーダー1のプル・イン使用可能の値がNoに変更された場合にどうなるかを確認します。
1つのオーダーの改善を考慮しない場合の計画結果
プランが実行され、オーダー1は改善対象として考慮されませんでした。 表に新しい計画日が表示されます。
|
オーダー番号 |
計算済優先度 |
要求日 |
要求数量 |
予定日 |
計画日 |
プル・イン使用可能 |
|---|---|---|---|---|---|---|
|
オーダー 1 |
10 |
01/04/2020 |
10 |
01/15/2020 |
01/15/2020 |
No |
|
オーダー 2 |
20 |
01/06/2020 |
4 |
01/15/2020 |
01/11/2020 |
Yes |
|
オーダー 3 |
30 |
01/12/2020 |
6 |
01/15/2020 |
01/12/2020 |
Yes |
オーダー1の計画日は、その予定日と同じであると推測します。 これは、改善が考慮されなかったためです。 01/11に使用可能な10ユニットの供給を使用して、4ユニットと6ユニットがリクエストされたオーダー2と3の需要を満たすことができるため、計画日は予定日より後に改善されます。 10ユニットの供給は01/15に利用可能であり、この供給はオーダー1の履行に使用されます。
オーダー明細がリクエスト日より早く計画された場合のプランニング結果
到着タイプ・オーダーが50ユニットで、リクエスト日が01/11/2030で、別の到着タイプ・オーダーが50ユニットで、リクエスト日が2030年1月13日であるとします。 顧客の受入カレンダに従って、顧客は木曜日にのみ作業します。
計画実行のキー設定- 単純需要優先度ルールREQDATEを選択し、リクエスト日によってのみ需要に優先順位を付けます。 最も早いリクエスト日のオーダーの優先度が高くなります。
- 出荷元組織から顧客への移動時間は0です。
- 両方のオーダーのプル・イン有効値は「はい」です。
プランが実行され、表に新しい計画日が表示されます。
|
オーダー番号 |
計算済優先度 |
要求日 |
要求数量 |
予定日 |
計画日 |
計画到着日 |
|---|---|---|---|---|---|---|
|
オーダー 1 |
10 |
01/11/2030 |
50 |
01/17/2030 |
01/10/2030 |
01/10/2030 |
|
オーダー 2 |
20 |
01/13/2030 |
50 |
01/17/2030 |
01/10/2030 |
01/10/2030 |
顧客の受入カレンダを尊重し、履行遅延を回避するために、最も近い木曜日の(01/10/2030)に計画日がスケジュールされていることを確認できます。
Oracle Backlog Managementがリクエスト日より前に計画日をスケジュールする場合、次の点を考慮する必要があります:
- 計画出荷日または計画到着日は、最早許容日が「バックログ分析」ページで指定されていない場合でも、リクエスト日より前の日付に上書きおよび再スケジュールできます。
- バックログ管理では、オーダーがリクエスト日より近くに再スケジュールされ、最早許容日がリクエスト日よりはるかに早い場合、オーダーが最早許容日に近づくことは促進されません。
- 最も早い受理可能日はリクエスト日として扱われないため、最も早い受理可能日によるオーダーの迅速化と早期計画は行われません。
- 「バックログ分析」ページでは、計画日がリクエスト日以前である可能性がありますが、制約および最早許容日に従って、リクエスト日に可能なかぎり近い日付になります。
- 最早許容日が指定されていない場合に、要求日を基準にして計画日がどれだけ早くなるかについて制限はありません。 ただし、これは、バックログ管理ができるだけ早くオーダーを計画することを意味しません。