フローを定義する

説明

ここで、予測を作成する需要を定義します。サプライチェーンでは、さまざまなサイトからさまざまな顧客へのさまざまな品目のフローがあります。フローは、これらのフローの 1 つに含まれるトランザクションのサブセットであり、通常は受注オーダ明細にあるトランザクションに基づいています。異なるフローにより、需要をグループに分割し、グループごとに個別の予測を行うことが可能になります。

wpe4.jpg (6284 バイト)

上の図は、倉庫 (IFS の典型的なサイト) から 2 つの顧客グループへの品目のフローを表しています。フロー 1 は顧客グループ1 (C1) からの需要を表し、フロー 2 は顧客グループ2 (C2) からの需要を表します。これらのフローは、さらに小さな部分に分割できないため、基本フローと呼ばれます。グループ内にある特定の顧客からの需要を把握することは不可能です。

基本フローは、特定の流通チャネルからの需要を表します。基本フローごとに、フローに含まれるトランザクションを定義します。次に、トランザクションは期間 (期間バージョンによって定義) に集計され、フローごとに予測が行われます。各基本フローには独自の予測品目のセットがあります。各品目には過去の需要と予測が含まれます。

倉庫から発生するすべての需要を予測する場合は、フロー 1 とフロー 2 からの需要を含むフロー 3 という新しいフローを作成できます。これは統合フローと呼ばれ、2 つ以上の基本フローを含みます。統合フローの需要は、基本フローで見つかった需要を集計することによって計算されます。調整済予測についても同様です。この集計は、需要予測サーバーで即座に実行されます。したがって、フロー 1 の調整済予測を変更すると、フロー 3 の調整済予測に直接影響します。同様に、フロー 3 の調整済予測が 10% 増加すると、フロー 1 とフロー 2 の両方の予測が 10% 増加します。

基本フローおよび統合フローに加えて、インポートされたフローがあります。インポートされたフローは、他の需要予測サーバーによって作成されたフローを電子メール経由で受入することを除いて、基本フローと同じです。この需要予測サーバーから他の需要予測サーバーにエクスポートするフローを設定することもできます。同じフローを複数の需要予測サーバーに配布できます。受信サーバーには、送信サーバーからエクスポートされたフローを保存するためのインポートされたフローがいくつか必要です。

需要予測サーバー設定、基本フローリストで利用可能なフィールド情報については、以下で説明します

フロー ID:フローの ID。自動生成され、読み取り専用です。

フローの説明:フローの特性。

サイトID:基本フローの発生サイト。このフィールドは必須です。

サイト名称:サイトの読み取り専用仕様。

マスター フロー:基本フローがマスター フローであるかどうかを指定します。マスター フローの予測は予測日タブにエクスポートされ、他の IFS モジュールで使用できるようになります。これらの予測は、サイトID フィールドにあるサイトにエクスポートされます。つまり、特定のサイトに接続されたフローのうち 1 つだけをマスターにすることができます。サイトに接続されているフローのいずれもマスター フローでない場合、予測は予測日タブにエクスポートされません。

書き戻しフロー:ここで「はい」を選択すると、マスター フローであるかどうかに関係なく、フローが FORECAST_FLOW_DAY_PUB に書き戻されます。フローは、マスター フローが FORECAST_DAY_PUB に書き戻されるのと同じ方法で書き戻されます。唯一の違いは、異なるフローを区別するために、フロー ID が FORECAST_FLOW_DAY_PUB ビューに含まれていることです。

予測別:このフィールドで使用可能な設定は、サイト/製造 DPインポート予測別フィールドの設定によって決まります。品目に設定すると、基本フロー予測は、サイトのマスタフローとして設定されている場合にのみ、他の IFS コンポーネントで使用できるようになります。このフィールドのその他の可能な設定は、顧客、顧客統計グループ、マーケット、地域、地区、または国です。使用できる設定は、品目と、サイト/製造/DPインポート予測基準で設定された設定の 2 つだけであることに注意してください。これらのいずれか (品目とは異なる) に設定すると、基本フローSQL は、ID で定義されたディメンションによって選択された予測の関連履歴を取得必要があります (以下を参照してください)。これらの他の設定のいずれかが定義されている場合、フローの予測は、顧客ディメンション別にマスタスケジューリングでインポートできるようになり、ディメンション別にエクスポートされた予測画面で結果の予測を確認できます。

ID 別予測:使用可能な設定は、予測基準 (サイト/製造/DPインポート予測基準) の設定によって決まります。予測基準が品目に設定されている場合、このフィールドの設定は使用されません。ID 別予測 が他の値 (顧客、顧客統計グループ、マーケット、地域、地区、または国) に設定されている場合。ここでの値によって、エクスポートされたディメンション別の予測ビュー/画面のキーが決定され、このフローが選択したディメンション別の予測のマスター フローになります。基本フロー SQL は、このフィールドの設定に対応する履歴データを収集する必要があります。たとえば、予測元設定が顧客 (サイト/製造業設定で定義) で、ID 別予測設定が Cust1 であるとします。基本フロー SQL の例は、SELECT contract, part_no, issue_date, issue_qty FROM comb_ext_inv_part_issue_pub WHERE customer_no='Cust1' となります。

SQL ステートメント:これは、過去の需要を集計するために使用されるトランザクションを定義します。この SQL ステートメントは、次の一般的な形式に従って記述する必要があります。

SELECT site(contract), part_no, date, quantity

FROM some_table

WHERE some_field = some_thing AND some_field = some_thing_else

フィールド サイト、品目番号、日付、および数量は、この順序で表示される必要があります。FROM ステートメントには結合のないテーブルを 1 つのみリストする必要があります。これは、SQL ステートメントが実行される前に需要予測計画担当者サーバーによって変更されるため、必要な制限です。サーバーは、フローのサイトに接続するトランザクションのみがフローに含まれるようにするために、where 句、サイト= 接続済サイトを設定します。サーバーは where 句も追加して、トランザクションの時間範囲を制限します。

このフローの設定方法では最大限の柔軟性が得られますが、エラーが発生しやすくなります。これに対抗するために、事前定義されたビュー Internal_Invent_Part_Issue_Pub と External_Invent_Part_Issue_Pub を作成しました。可能な限り、これらのビューを使用する必要があります。ビューから直接選択する場合は、次の落とし穴に注意してください。

Internal_Invent_Part_Issue_Pub の使用

Internal_Invent_Part_Issue_Pub には、品目の内部消費がすべて含まれており、次のように定義できます。

SELECT contract, part_no, date_issued, qty_issued FROM Internal_Invent_Part_Issue_Pub

External_Invent_Part_Issue_Pub の使用

すべての外部消費 (受注オーダ数量) は次のように定義できます。

SELECT contract, part_no, issue_date, issue_qty FROM External_Invent_Part_Issue_Pub

ここでは、例に示すように、出庫数量と日付に基づいて予測を定義することも、希望、約束、または計画された数量と日付を使用することもできます。この方法では、納入可能な数量と日付ではなく、顧客が希望する数量と日付を設定できます。

顧客 (cust1) によるサイト上のすべての外部消費のフローは次のように定義されます。

SELECT contract, part_no, issue_date, issue_qty FROM External_Invent_Part_Issue_Pub WHERE Customer_no = 'cust1'

Comb_Ext_Inv_Part_Issue_Pub の使用

このビューは、External_Invent_part_Issue_Pub と、マニュアルの過去の需要予測データ画面に追加されたトランザクションとの結合です。このビューは、他のシステムから IFS 需要予測にトランザクションをインポートして、システム内の実際の IFS 受注オーダーの期間よりも長い履歴データを取得する場合に最適です。

顧客 (cust1) によるサイト上のすべての外部消費のフローは次のように定義されます。

SELECT contract, part_no, issue_date, issue_qty FROM comb_ext_inv_part_issue_pub WHERE customer_no='Cust1'

IFS 要求管理からのデータ

IFS 要求管理から完了データを取得する 2 つの新しいビューが作成されました。

Planned_Material_Demand -再実行サービスで計画され (将来の需要)、要求作業工程で消費される資材 (過去の計画需要)。これは、計画された予防サービスから発生する需要/トランザクションです。

このビューは次のフィールドで構成されています

名前 タイプ 説明
CONTRACT VARCHAR2(5) 消費元の契約/サイト
PART_NO VARCHAR2(25) 使用される品目番号
PLANNED_DATE 日付: 使用予定日
PLANNED_QTY 番号: 使用予定数量
ISSUE_DATE 日付: 実際の使用日
ISSUE_QTY 番号: 実際の使用量
CUSTOMER_NO VARCHAR2(20) サービスの提供を受けた顧客
SERVICE_ORGANIZATION VARCHAR2(20) サービスを提供したサービス組織
SERVICE_DELIVERY_UNIT VARCHAR2(20) サービスを提供したサービス納入単位

UnPlanned_Material_Demand -要求作業工程で消費された資材 (履歴未計画需要)。これは、計画された予防保守の一部ではないサービス/修理から発生する需要/トランザクションであり、是正サービス需要とも呼ばれます。

このビューは次のフィールドで構成されています

名前 タイプ 説明
CONTRACT VARCHAR2(5) 消費元の契約/サイト
PART_NO VARCHAR2(25) 使用される品目番号
ISSUE_DATE 日付: 実際の使用日
ISSUE_QTY 番号: 実際に使用した量
CUSTOMER_NO VARCHAR2(20) サービスの提供を受けた顧客
SERVICE_ORGANIZATION VARCHAR2(20) サービスを提供したサービス組織
SERVICE_DELIVERY_UNIT VARCHAR2(20) サービスを提供したサービス納入単位

これらのビューは、 IFS Cloud 内でサービスおよびメンテナンスで使用される品目を管理するための、より広範なロジスティクスサポートフレームワークの一部として利用されることを目的としています。目的は、需要予測を活用して、サービス工程に関連する将来の需要の予測を生成することです (要求管理)。この包括的な予測は、在庫計画および補充 (IPR) の入力として使用され、要求管理/サービス処理で必要な品目の再発注点、安全在庫レベル、ロットサイズを決定します。

このアプローチにより、最適な在庫レベルが確保され、サービス需要に効果的に対応できます。IPR は、システム内で利用可能なモデル の特殊な組み合わせを使用して構成する必要があることに注意することが重要です。推奨事項は次のとおりです。

需要モデル:予測

安全ストロックモデル:カバー日数または平均絶対誤差

ロットサイズモデル:実際に最も関連性の高いモデルはどれでも使用できます(カバー日数、経済的ロットサイズ、動的範囲)

発注点モデル:リードタイム主導

これらから逸脱する理由があるかもしれませんが、これらの組み合わせが基本ラインになるはずです。

需要予測における一般的な設定は、次の基本フローになります。

サービスサイトS1 - 計画需要ベースフロー SQL "SELECT contract、part_no、issue_date、issue_qty FROM planed_material_demand"

サービスサイトS1 - 計画外需要ベースフロー SQL "SELECT contract、part_no、issue_date、issue_qty FROM unplanned_material_demand"

次に、サービスサイトS1 の 2 つの基本フローで構成される結合フローを作成します。この結合フローは、サービスサイトS1 のマスターとなり、IPRでのさらなる計画に使用されます。

重要

需要予測サーバーは高度な SQL 用に設計されていないため、ネストされた SQL ステートメントは使用しないでください。簡潔にしてください。

SELECT contract, part_no, issue_date, issue_qty FROM External_Invent_Part_Issue_Pub WHERE <いくつかの句>

アプリ所有者以外のユーザーから DP サーバーを実行する予定の場合は、必ず APPOWNER を接頭辞として付けてください。

前提条件

システムへの影響

サーバーが起動されるまでシステムへの影響はありません。