シナリオノードバランシングコストの最適化

のOptimization serviceノードバランスを考慮して注文を最適化する機能を提供します。たとえば、買い物のピーク時に高い需要を満たしたい場合、配送コストよりもノードのバランスを優先することができます。

電子商取引の需要は、特にショッピングシーズンのピーク時には毎年高まっています。昨年の休暇期間中、注文が特定の店舗に割り当てられたときに、フルフィルメントのすべての側面が考慮されていなかったため、店舗のバックログが大量に発生しました。

電子商取引ビジネスが成長する一方で、Optimization serviceすべてのノード（店舗と配送センター）を考慮して注文を最適化します。繁忙期には、配送コストよりもネットワークの負荷分散や顧客へのSLAを優先した方がよいかもしれません。のOptimization service顧客の期待に応えながら、注文を最適化してサービスにかかるコストを最低限に抑えるのに役立ちます。

既存のノードと配送センターを使用して注文処理を最適化することで、企業はショッピングのピーク時に高い e コマース需要を満たすことができます。業務の優先順位を設定することで業務の滞りを防ぐことができ、システムは各注文を Optimization service 最適化して処理し、業務の滞りを回避します。

容量コストの計算は次の関数ですCapacityConsumed、

Node
Balancing Values

、Daily Capacity (Processing Plan) 、そして

quantity
(input of Optimizer Call)

船舶ノードで最適化されています。

詳細については、次の定義を参照してください。

たとえば、 Store1 および Store2 の構成に、以下のコストが含まれている場合：

ノード ID	バックログ日数	タイブレーカーコスト	生産能力過剰ペナルティー	容量（処理計画）
Store1	0.9	0.2米ドル	3.5米ドル	1日30ユニット
Store2	1.1	0.2米ドル	3米ドル	1日あたり40ユニット

したがって、 Store1 と store2 の送料や手数料などのその他のコストが同じ場合、容量コストが最適化の判断を左右することになります。

閾値に達していない場合

需要は、タイブレークのコストに基づいて調整されます。計算内容については、次の表をご覧ください。

注文は以下に割り当てられますStore1 、それからStore2 、そして再びStore1しきい値に達するまで。「 Store1 」と「 Store2 」は、サイズがほぼ同じで、タイブレークのコストも同一です。同様の仕組みはネットワークレベルでも見られ、そこでネットワーク全体で需要のバランスが取られています。

注：負荷分散を制御するには、ノード負荷分散カレンダーを設定してください。通常日の閾値は、1日未満、2日、または3日に設定できます。そうすれば、休日や繁忙期には閾値を高く設定し、ネットワーク全体で需要のバランスを調整することができます。

時系列	Store1	Store2
T(1)	1個	1個
T(2)	1個	数量 2
T(3)	数量 2	数量 2
T(4)	数量 2	3個
T(N)	1日の処理能力が低いため、先に閾値に達した	まだ基準値を下回っている可能性がある

T(N)はT(2)より大きく、T(2)はT(1)より大きい。
時刻 T において、どの注文についても、特定の注文行に対して 2 件の割り当てが存在する。

時系列	Store1	Store2	最適化結果	コメント
T(1)	`CapacityConsumed` = 1 CCU = 0.03333 `CapacityCost` = 0.000222	`CapacityConsumed`= 1 CCU = 0.025 `CapacityCost` = 0.000125	Store2	キャパシティコストには、タイブレークコストのみが算入されています。ノード間でも状況が同じであるため、CCUが主要な要因となります。
T(2)	`CapacityConsumed` = 1 CCU = 0.03333 `CapacityCost` = 0.000222	`CapacityConsumed`= 2 CCU = 0.050 `CapacityCost` = 0.0005	Store1	需要は Store2 に割り当てられているため、 Order Management System (OMS)は、 Store2 に対して CapacityConsumed を2として提供する必要があります
T(3)	`CapacityConsumed` = 2 CCU = 0.0666 `CapacityCost` = 0.000222	`CapacityConsumed`= 2 CCU = 0.050 `CapacityCost` = 0.0005	Store2	需要のバランス状況を確認してください。現在、需要は Store1 に割り当てられています。各店舗の平均稼働率が上昇するにつれ、このバランス調整のサイクルは続いていく。

この需要の調整は、いずれかの船舶ノードが閾値に達するまで続けられる。

たとえば、 Store2 のタイブレーカー値が 0.5 米ドルよりも高い場合、初期配分は、完全利用率が Store2 のコストと同等になるまで、 Store1 にのみ適用されます。このような場合、各店舗間の需要配分のパターンは異なります。対象ユーザー向け

しきい値に達したとき

「例」の同じ例について、ロードバランシングの効果 CapacityConsumed を示すために値が適用されています。この値は、設定されたノード負荷分散カレンダーの値に基づいた実際の需要配分を反映していない可能性があります。

時系列	Store1	Store2	最適化結果	コメント
T(1)	`CapacityConsumed`= 33 CCU = 1.1 `CapacityCost` = 4.2605	`CapacityConsumed`= 42 CCU = 1.05 `CapacityCost` = 0.055125	Store2	Store2 は閾値を下回っており、 Store1crosses は閾値を上回っているため、 Store1 に対してペナルティが適用されます。
T(2)	`CapacityConsumed`= 65 CCU = 2.2 `CapacityCost` = 8.157	`CapacityConsumed`= 48 CCU = 1.2 `CapacityCost` = 3.372	Store2	しかし、両社とも目標を達成したものの、 Store1 の方が受注残が多い。

注： Store1 には CapacityCost8.157 米ドルに対し、CCUが 2.2 の場合は 4.2605 米ドルであり、T(1)とT(2)では、バックログの単位ごとに適用されるペナルティです。

容量がゼロに設定されている場合

例えば、ある期間（たとえば今後7日間）について、加工計画または生産能力が0に設定されている場合、累積稼働率（CCU）の計算時には特別な条件が適用されます。次のシナリオを考えてみましょう。

今後7日間の加工計画または生産能力は0に設定されています。
入力によると、容量の消費量は3単位となっています。

この場合、は Optimization service 以下の基本ルールを適用します：

CCUの計算中、すべての日のキャパシティが0であるため、オプティマイザーはCCUの最大値である7を使用します。
CCUが最大値に達すると、オプティマイザーは500米ドルの固定容量コストを割り当てます。
このシナリオでは、キャパシティがゼロという状態が通常の負荷分散動作よりも優先されるため、ノード負荷分散カレンダー（NBC）の設定は考慮されません。

重要：これらの内部ルールは、容量が利用できない場合に一貫した動作を確保するためのものです。容量を 0 に設定すると、そのノードは新たな割り当てを受けないことを示します。その結果、500米ドルという高い固定コストにより、他に選択肢がない場合を除き、オプティマイザーがこのノードを回避するよう保証される。