3.4.1. データタイプ

需要計画や売上金額予測や在庫最適化などユーザーの目的に応じて、必要なデータは異なります。この節では、各場合別の必要データを説明します。

GMDH Streamlineは、広範囲のデータタイプをインポートします。それらは、以下のデータ要素に論理的に分割できます。:

• 取引データ。 販売取引、またはすべての在庫移動取引データで構成され、頻繁に変更されるデータです。

• 品目情報。 属性を表すデータの組み合わせで構成され、各計画品目を特徴づけます。一般的には静的なデータで、ほとんど変更されないデータです。

• 入荷オーダー情報。このグループのデータタイプは、未完了の製造オーダー、移動オーダー、購入オーダーに関する製品を表します。現在時点で、積送中や製造中も対象になります。

• 出荷オーダー情報。顧客に出荷すべき品目に関するデータで、未完了販売オーダーやバックオーダーが例になります。

• 部品表 。製品品目の構成部品に関するデータタイプです。資材所要量計画に利用されます。

• 販売促進情報。GMDH Streamlineが、予測立案時に、将来の販売促進を考慮するための情報です。販売促進を頻繁に実施し、さらに需要が販売促進の値引きに依存する場合、データの用意が必要です。

• 置換情報。在庫にキット品目があり、キット品目の構成部品別に予測と在庫計画立案したい場合、GMDH Streamlineは自動でキット品目を構成部品に分解し、これらの情報を考慮します。このグループのデータタイプは、分解済みキット品目の計画に利用されます。

各販売データや各在庫移動データは、ERPデータベースに取引としてあらわされるのが一般的です。取引は、いつ、どこで、何を、どれだけ販売したのか(あるいは在庫水準が変更されたのか)を表します。このセクションでは、ユーザーが用意する必要な取引データのデータタイプと任意の取引データのデータタイプを説明します。

• 需要計画
• 売上金額予測
• 在庫計画
• 在庫KPI

需要計画のための基本的な取引データを下記の一覧表に紹介します。:

(例えば、店舗や倉庫や地域などの)地点、さらにチャネル別の予測を必要とする場合、取引データは、下記の一覧表にあるデータが必要です。:

地点またはチャネルの空の文字列は、対象取引に地点またはチャネルの組み合わせがないことを意味します。

売上金額予測するためには、取引データに加え、下記の一覧表あるデータタイプが1つ必要です。:

この情報は、売上を基礎とするABC分析、年次売上金額、翌年次売上金額、粗利益率、交差比率などの販売金額に依存したKPIの計算にも利用されます。

補充計画を立案し、潜在的な欠品と過剰在庫を検出し、購入オーダーを作成するには、品目手持ち在庫情報が必要です。

品目手持ち在庫のインポートには、下記の一覧表の内の1つが必要です。

第2タイプと第3タイプからデータを提供し、手持ち在庫をインポートする場合、次が可能になります。²⁾

• 在庫回転率の計算
• 期間中に在庫が欠品した日数の計算(欠品日数)
• 機会損失の原因が自動で選択されます。選択される原因は、欠品と需要がないのどちらかになります。販売数0は欠品が原因のオプションをユーザー自身で設定する手間を減らすことができます。

GMDH Streamlineに各取引の利益を設定するには、次のデータタイプをインポートします。

GMDH Streamlineはこの値から、各データ集計期間の総粗利額と直前12か月の総粗利額の計算をします。

品目情報の最重要目的は、GMDH Streamlineに各計画品目の手持ち在庫数量を用意することです。そのため、手持ち在庫数量には品目IDが必要です。地点を利用しない場合、品目IDは、品目コードになります。地点を利用する場合、品目IDは、品目コードと地点の組み合わせになります。品目情報からインポートする手持ち在庫数量のデータタイプは、以前のセクションにて説明済みです。

手持ち在庫水準に追加できるデータタイプのデータ要素は、以下です。:

• 分類レベルの需要計画
• 一般的な在庫計画
• 特定の在庫計画:
  • 在庫最適化時の制約の考慮
  • 複数物流センターを持つ2段階計画
  • 特定区域内の内部倉庫移動計画
  • 保存期限を持つ品目の計画

GMDH Streamlineは、分類レベルの需要計画ができます。これは、分類ツリーのすべてのレベルで、予測オプションとユーザー自身の予測上書きの作成ができることを意味します。これを行うためには、下記の一覧表にて紹介されているデータが必要です。:

インポートできる分類数には制限がないため、必要な数だけインポートできます。

品目コードと地点以外にも、下記の一覧表にあるデータを追加できます。:

データソースにリードタイムやオーダーサイクルに関連するデータがある場合、下記の一覧表にて紹介するデータタイプ経由でデータをインポートできます。

リードタイム分散を追加で設定することで、さらにレポートの精度を高めることができます (下記の一覧表を参照)。

在庫を最適化には、最終 手持ち在庫、リードタイム、オーダーサイクル、その他の多くの入力が利用されます。 安全在庫は最適な 購入計画の決定に利用されるため、これを入力の1つと考えることができます。

GMDH Streamlineが安全在庫を計算する場合、2つの基礎的な計算方法があります。1つ目の計算方法は、サービス率を基礎とするよく知られた計算方法です。GMDH Streamlineでは、この計算方法を実装し、データベースから各計画品目のサービス率のインポートにも対応します。2つ目の計算方法は、将来需要に基づく計算方法です。特定の計画品目に対して、安全在庫として持ちたい需要の期間数を設定する方法です。

下記の一覧表にて、これらデータタイプを説明します。

GMDH Streamlineは、予測欠品在庫、粗利益率、その他の測定基準などの、重要在庫指標(KPI)の計算ができます。下記の一覧表にて、必要なデータタイプを説明します。

購入金額/単位は、推奨購入オーダーの金額の計算に利用されます。KPIのいくつか(例えば、年次売上金額、翌年次売上金額とその他)には、販売価格/単位または取引売上金額のインポートが必要です。

下記の一覧表にて、設定可能な購入先情報を説明します。

在庫最適化時に、制約を考慮できます。制約は2種類あり、1つはオーダー品目数量に関する制約であり、もう1つは総量として購入オーダーに関する制約です。下記の一覧表にて、制約データタイプを説明します。

購入オーダーに関する制約は、購入先コードと関連します。購入先コードが設定されない場合は、空の購入先が設定されます。物流センターから供給される計画品目に購入先コードがあり、さらにいくつかの制約が設定された場合、これらの制約は適用されません。

2段階計画ができます。

単一の物流センター (DC)を持つ場合、追加データを必要とせずに、DC 設定内にあるオプションを設定ができます。しかしこの場合は、複数の地点のなかで1つの地点だけが購入先から直接供給される状況を考慮する機能は一切利用されません(つまり、DCは意図的に利用されないことになります。)。

複数のDCを持つ場合、データベース 接続を利用し複数のDCのインポートと設定ができます。この場合:

• 追加情報が必要です(下記)。
• 物流センターは常に有効となり、設定の地点コントロールは無効になります。
• 地点は、物流センターを経由せずに購入先から直接供給されることもできます。
• DC 設定内のオプションは、ユーザーが管理するすべての物流センターに一括して適用されます。

インポートできる物流センターの数には制限がなく、特定の物流センターから供給を受ける地点を品目別に設定できます。これには、(地点、DC 名、品目コード)の3つの組み合わせで設定が必要です。例えば、(西日本、西日本 物流センター、ダークチョコレート) の3つの組み合わせは、物流センター:西日本 物流センターは、品目:ダークチョコレートを地点:西日本に供給することを意味します。

物流センター - 地点 の関係は、2つの制限があります。:

• 2つ(またはそれ以上)の物流センターは、同じ品目を同じ地点に供給できない⁴⁾。
• 物流センターは他の物流センターに供給できない、つまり物流センターと地点の関係だけが設定可能

この関係の設定は、品目情報クエリにDC 名データタイプの追加が必要です。DC 名は、上記で説明した(地点、DC 名、品目コード)の3つの組み合わせのDC 名になります。

この時点で、GMDH Streamlineに関係を正しく設定できる品目情報クエリのデータタイプを説明できます。

上記で説明しましたが、3つの組み合わせを設定するには、品目情報クエリに次の3つのデータ列が必要です。: 地点、DC 名、品目コード。下記の一覧表にて、SQL クエリが用意すべき、レコード例を表示します。

各物流センター - 地点 - 品目 の関係に対して、一覧表はSQL クエリが2レコード返す必要があることを示します。第1レコードは、物流センター:DC1から地点:Aへのリンクを表し、Item1はDC1から地点:Aへ供給されます。第2レコードは、DC1がItem1を保存する地点として宣言します。

ある品目が物流センターを経由せずに購入先から直接地点に供給される状況を設定するには、SQL クエリは下記の一覧表に表示されているレコードが必要です。一覧表は例となるレコードを表示します。

下記の図で用意されている例を考えます。

この場合、SQL クエリは下記の一覧表にあるレコードが必要です。

少なくとも1か所の保管所が過剰在庫であるとき、GMDH Streamlineは、保管所間の在庫移動の計画立案ができます。デフォルトでは、最小から最大になる現在のオーダーを満たすために、過剰在庫を消費し、補充対象の保管所数の最大化します。

さらに、移動が許可される区域を導入することで、上記ルールに制約を追加できます。制約は、各地点が所属する区域の組み合わせで設定します(下記の一覧表を参照)。

異なる区域に属する地点間では、移動は発生しません。それと同時に、移動は、同じ区域に属する地点間で、許可されます。

これらの制約任意です、つまり移動区域 データタイプは隙間を持つことがあります、つまり、内部倉庫移動に関係しない地点を定義できます。

保存期限を持つ品目の計画ができます。品目保存期限は、2つの単位で設定できます(下記の一覧表を参照)。

保存期限 パラメータは、在庫最適化の制約として利用されます。今回のオーダー 数量の最長期限は、設定された保存期限 期間と立案された需要予測から計算されます。

この情報は、未完了の製造オーダー、未完了の移動オーダー、未完了の製造オーダーがあることを示します。これには、積送中の在庫と製造中の在庫も含まれます。

下記の一覧表にて、データタイプを(オーダーを区別することなく)説明します。

次の一覧表にて、オーダータイプ別の期待入荷日付決定方法を紹介します。

一覧表から次のことがわかります。:

• 移動の場合、内部倉庫移動と物流センターから供給される計画品目をインポートすると、物流センターから保管所へのリードタイムを考慮します。

• 内部倉庫移動と物流センターから供給されない計画品目をインポートすると、配送時間を1日とします。つまり、同じ地点内の保管所間は、1日の距離であるとします。

• 製造リードタイムは、考慮されません。インポートされた数量は手持ち在庫に加算され、加算後の(あるいは訂正後)手持ち在庫は結果を計算するための入力として利用されます。

将来の手持ち在庫をより正確に計算するため、顧客への出荷オーダーに関する情報を考慮できます。出荷オーダーは、未完了販売オーダーまたは一時品切れまたは入荷待ち(バックオーダー)とも呼ばれます。

下記の一覧表にて、データタイプを(オーダーを区別することなく)説明します。

部品表情報は、製品品目の構成部品を表示します。構成部品は、中間品目(製造を目的とした中間階層に位置する)や材料品目(製造の最下位に位置する)と考えることができます。インポートできる組み立ての階層数には、制限がありません。

GMDH Streamlineは、バッチ生産の部品表をサポートします。言い換えると、部品表は、製品品目のまとめ生産数量に利用される構成部品とその数量を記載します⁵⁾。

下記の一覧表にて、資材所要量計画に必要なデータタイプを説明します。

予測モデル作成時に、GMDH Streamlineは、与えられた販売促進を自動で考慮します。下記の一覧表にて、必要なデータを説明します。

将来の販売促進を考慮するため、過去の販売促進の値引率を設定し、同じフォーマットで将来の値引率が必要です(例を見る)。

すべての地点で一斉に行われた販売促進を考慮する場合、地点列に空の文字列を設定します。

キット品目⁶⁾を在庫に持ち、それらの構成部品別に予測や計画を立案したい場合、 この情報をから自動的にキット品目を分解します。下記の一覧表にて、必要なデータタイプを説明します。

次へ: データインポート

PDFダウンロード