リリース12.2
E57802-01
目次
前へ
次へ
| Oracle Demantra Demand Managementユーザー・ガイド リリース12.2 E57802-01 | 目次 | 前へ | 次へ |
この章では、次のトピックについて説明します。
Oracle Demand Managementは構成可能なWebベースの製品で、組織が需要計画および予測を行う際に役立ちます。需要管理はコラボレーションを中心に構築されており、ワークフローを活用して需要管理プロセスを自動化します。
通常、需要計画のプロセスでは、販売履歴データを調査し、将来の需要をできるかぎり詳細に予測します。顧客の需要をできるかぎり迅速に満たしながら、各製品を必要な分のみ製造または購入するようにバランスを取ることが目標です。
需要計画は予測に基づいています。予測はある期間にわたってサプライ・チェーンの傾向を予想したもので、季節やその他の予測可能な要因の影響を受けます。予測の結果は、傾向を示し例外的な変化を重視しないように平滑化された予測曲線になります。
通常、需要計画と予測は生産計画などのダウンストリーム工程で使用されます。システムの構成方法により、このようなデータを自動的にエクスポートするか、その目的に使用するレポートを含みます。
需要管理は反復プロセスで、通常は週1回、2週間に1回または月1回のサイクルで行われます。このプロセスには次のものが含まれます。
ERPまたは他の記録体系からの適切なデータを収集します。
Demantraデータベースに適切なデータをダウンロードします。
予測を生成し、需要アナリストに通知を送信します。
需要アナリストは予測を操作し、修正または調整を行います。
需要マネージャまたは指定された予測所有者は、予測を承認します。
承認された予測はERPシステムにアップロードされます。
ほとんどの業務には、毎月、毎週または毎日(少数)行われる定期的な需要管理プロセスがあります。この期間中に、将来の需要を予測するために、様々なソースが需要管理システムにロードされます。ソース・システムは、ERPシステム、レガシー・システム、またはAdvanced Supply Chain Planning、Inventory Optimization、Global Order Promising、Collaborative Planningなどの他のOracle APS (Advanced Planning Suite)モジュールになります。
ソースがロードされると、管理者はプランナが必要とするデータへのアクセス権を持っていることを確認します。たとえば、各プランナは特定の地域や製品ラインの需要を計画できます。プランナはアクセス権が付与されているすべてのライン・オブ・ビジネスのデータを表示できますが、実行できるのは権限を持つデータの変更のみです。
ダウンロードが完了すると、管理者(または自動化されたプロセス)は予測を実行し、承認シリーズをリセットします。予測が正常に計算されると、予測がレビュー可能であるという通知が自動的に該当するユーザーに送信されます。すべてのユーザーが、事前定義済ワークシートで予測、予測精度メジャーおよび需要優先度情報を分析に使用できます。
注意: ダウンロードや予測生成に失敗した場合、管理者は処理および予測生成中に発生した問題の詳細をバッチ・ログで確認できます。
承認プロセスは、需要管理者と需要アナリストの2つのユーザー・タイプを中心に構築されます。実装時に、需要管理者は、予測の最終承認を行うレビュー担当者を指定することで、承認プロセスを構成します。需要アナリストの各グループには、1人の最終承認者が必要です。
承認プロセスの開始時に、現在の計画サイクルに予測を使用できることを需要アナリストに通知する、「自分のタスク」ウィンドウが表示されます。アナリストは、事前にシードされたワークシートの1つを使用して、計画データ(予測を含む)をレビューできます。
ウォーターフォール分析: 製品カテゴリとゾーン
ウォーターフォール分析: 製品カテゴリと組織
需要分析: 製品カテゴリと組織
需要分析: 製品カテゴリとゾーン
需要分析: 品目と組織
需要分析: 品目とゾーン
アナリストはこれらのワークシートにあるグラフとレポートを使用して、予測データを表示および修正します。アナリストは履歴を分析して、出荷済オーダー、記帳済オーダー、顧客オーダー、在庫レベルおよびその他の要因を把握します。たとえば、アナリストは顧客や販売予測に加えて需要にも影響する可能性のある次回のイベントや販促を考慮できます。
この情報に基づいて、アナリストは予測を変更し、ワークシートに変更されたデータを再移入するシミュレーションを実行できます。分析と変更が完了すると、アナリストは変更内容を保存し、コラボレータ・ワークベンチの「自分のタスク」ビューで関連する通知の「完了」を選択します。これにより、需要計画マネージャや管理者に通知が送信されます。
予測へのこれらの変更を、承認者によるレビューに使用できます。1人以上の人がレビューを実行できます。たとえば、アナリストが地域別の需要を担当する場合、地域マネージャはアナリストの変更を承認または変更できます。または、アナリストが製品ラインへの分割を担当する場合、製品ライン・マネージャは最終承認を実行できます。需要管理の事前にシードされた承認プロセスは、1つのレベルのレビュー用に設定されます。その他のレベルのレビューを行うには、事前にシードされた承認ワークフローを変更する必要があります。
最終承認者は、「最終承認」列を選択することでいつでも予測をロックできます。レビューの後、最終承認者は予測通知の「自分のタスク」で「完了」ボタンを選択することで、予測を承認します。
承認後、需要管理者は他のシステム(Oracle Advanced Supply Chain Planningなど)で使用できるように連結された予測をアップロードします。これらのシステムでは、制約のない需要を使用して制約のある需要を促進します。
通常、組織のデータは複数のライン・オブ・ビジネス(LOB)に分割されます。たとえば、プリンタ製造業者は、プリンタおよび複写機のライン・オブ・ビジネスを使用します。通常、ライン・オブ・ビジネスが異なると、需要管理プロセスも異なります。計画プロセスの違いは、次の理由によります。
ライン・オブ・ビジネスごとに計画サイクルが異なり(毎週、毎月など)、異なるカレンダ(製造、会計など)を使用します。
ライン・オブ・ビジネスごとにビジネス要件が異なります。たとえば、モデル・オプション予測、製品ファミリ・レベル予測、サービス・パーツ予測などがあります。
ライン・オブ・ビジネスの地理的な場所が異なるか、またはビジネス手法が異なります。
各ライン・オブ・ビジネスには、それぞれのライン・オブ・ビジネスのみに関連する需要データを参照する必要があるプランナの個別のグループがあります。
ライン・オブ・ビジネス需要計画では、ライン・オブ・ビジネスに関連するレベル値(品目、組織、顧客の出荷先事業所、営業担当など)のみを含むように、需要計画の範囲を制限します。
組織に複数のLOBがある場合、通常は(製品ラインや地域に基づいて)データが特定のユーザーに割り当てられ、アナリストがそのデータの区分の需要を判断します。各アナリストが需要をレビューおよび承認すると、マスター承認者に通知が送信され、予測全体が承認されます。
次の図は、複数のライン・オブ・ビジネスを持つ需要管理プロセスを示しています。
製品ファミリ部品構成表は通常、最上位に製品ファミリ品目が、そして1つ下のレベルに品目(子)がくるという構成になっています。
製品ファミリ部品構成表のサンプルを次に示します。
自動車
. セダン
. クーペ
. スポーツ
製品ファミリ計画において、製品ファミリのすべてのファミリ・メンバーは次の条件を満たしている必要があります。
個別に、または製品ファミリとして計画されている。
予測管理品目属性に対して、「なし」または消費および導出のいずれか同じ値が設定されている。
標準品目である。
品目レベルに正確な予測を作成するだけのデータがない場合、Oracle Demantra Demand Managementでは製品ファミリ・レベルで予測を行い、その製品ファミリ予測を子に割り当てます。
受注構成製品は、顧客の好みに基づく構成部品の構成です。ほとんどの場合、これには選択済の基本製品(モデル)と複数のオプション構成部品(オプション)および必須構成部品が含まれます。
受注構成は従属需要予測の原則で処理されます。従属需要予測は、需要が全面的にまたは部分的に他の製品の需要に依存する、部分依存または完全依存の製品の需要を予測する機能です。従属需要予測によって対処する一般的な問題には次のようなものがあります。
自動車製造業者の場合: アルミ合金ホイールまたはV6エンジンがいくつ売れるか。
パーソナル・コンピュータ製造業者の場合: ハード・ディスクを合計でいくつ製造する必要があるか。そのうち、新しいパーソナル・コンピュータの一部として販売するのはいくつで、個別に販売するのはいくつか。
受注構成製品はモデルとも呼ばれます。パーソナル・コンピュータを例に取ると、次のような製品があります。
オプション品目が顧客の要件によって組み立てられる。たとえば、パーソナル・コンピュータのオプションにモニターやキーボードが含まれる場合があります。
オプションの需要がモデルの需要に依存する。たとえば、デスクトップ・パーソナル・コンピュータの場合はモニタが必須となる場合があります。
オプションの確度は、ある品目が別の品目の購買時に購買される見込みです。
必須品目の場合、確度は100%です。
オプションの場合、確度は販売履歴に基づきます。
これらの中間品目の確度は、顧客の好みが異なるため、地域や販売チャネルによって異なってくる場合もあります。
この確度は必須構成部品とオプションの計画比率となり、それらの予測需要を導出するのに役立ちます。
受注構成の需要計画プロセスには次のプロセスが含まれます。
完成品の受注計画および管理: 新規アクティビティ、販売、マーケティングおよび履歴データの管理による入力に基づいて、モデルの将来的な、制約のない需要計画に同意するプロセスです。
構成部品の受注計画および管理: 必須構成部品とオプションの混合を予測するプロセスです。このプロセスでは、モデルの最終コンセンサス計画に必須構成部品とオプションの計画比率を乗算します。このプロセスは供給計画の一部ではありません。なぜならこれらの関係は需要計画プロセスの特性(たとえばオプション混合に対する販促およびその他の需要計画アクティビティの効果、および収益に対するオプション混合の効果)であるためです。
通常、構成可能なモデルおよびオプションを扱う場合、通常のOracle Demantra Demand Managementプロセスに従いながら、受注構成製品に一部変更を加えます。一般に、このビジネス・フローは次のとおりです。
モデルの販売履歴からモデル予測を導出する
モデル予測に計画比率を適用してオプションおよび必須品目の品目レベルの予測を計算する
コンセンサスに達するために複数のディメンションで必要となる品目レベルの予測を分析および更新する
供給計画に最終予測を発行する
受注構成の構造
受注構成の構造は一般に次のようになります。
. ベース・モデル
..オプション区分
... オプション(作成可能品目)
..必須構成部品(作成可能品目)
注意: オプション区分が含まれるかどうかは、プロファイル「MSD_DEM: 計画比率の計算」の設定によって決まります。
ベース・モデルの部品構成表は通常、次のもので構成されます。
ベース・モデル。
オプション区分にグループ化されたオプション: オプション区分は作成可能品目や販売可能品目ではありません。各オプション区分について、顧客は1つ以上のオプションを選択できます。オプションは別のモデルにすることができます。
必須構成部品/展開品目: これらはすべてのモデルの一部として含められます。
ベース・モデル部品構成表のサンプルを次に示します。
セダン
.. タイヤ
... 標準
... 長寿命
.. シート
... 布
... レザー
... ビニール・レザー
.. ルーフ・ラック
... ラゲッジ・スタイル
... 自転車スタイル
.. 使用マニュアル
ベース・モデルはセダンです。このセダンの部品構成表は次のようになっています。
オプション区分はタイヤ、シートおよびルーフ・ラックです。
オプションは標準、長寿命、布、レザー、ビニール・レザー、ラゲッジ・スタイルおよび自転車スタイルです。
必須構成部品は使用マニュアルです。
基本モデルには次のタイプがあります。
受注組立: 製造業者または販売業者が構成部品を組み立てて構成品目(自動車など)を出荷します。
受注ピック: 構成部品は個別に出荷され、受取者が組み立てます(子供の屋外用遊具など)。
計画比率
モジュラー製品の構成は、モデル構成表、およびモデルの販売に対するオプションの販売の比率の両方によって表されます。
Oracle Demantraでは品目(通常は基本モデル)に対し、その品目の独立履歴に基づいて独立需要予測を生成します。
モデルの部品構成表の各構成部品品目は計画ファクタです。計画ファクタはアタッチ・レート、つまりモデルの需要に対するオプションの比率、言い換えるとモデルのオーダー時に顧客がその構成部品品目をオーダーする確率です。
これらの比率は計画比率と呼ばれ、モデルに対するオプションの関係を表します。これらは、製品混合に変更があると予測に関連する需要に影響がある場合に需要計画プロセスにおいて導出する必要があります。さらに、販促およびその他の需要計画アクティビティによって販売中のオプションが変わる可能性もあります。
モデル需要を予測するだけでは十分ではなく、履歴比率(モデルに対するオプションの平均販売履歴)を使用して、相対売上に基づいてオプションや機能の混合を予測する必要があります。
注意: Oracle Demantraインプリメンテーション・ガイドのシステム・パラメータCTO_Enable_Worksheet_CalculationsおよびCTO_PLANNING_PERCENTAGE_CHOICEに関する項を参照してください。
部品構成表の展開
Oracle Demantraでは、従属品目(オプション区分、オプション、必須構成部品)の従属需要予測を、対応する部品構成表を使用してそれぞれの親から予測を展開することにより計算します。品目の従属需要は、計画比率に部品構成表で2番目に高いレベルの需要を乗算することによって計算されます。従属需要品目は、たとえば需要のサービス・パーツ部分というように単独で需要予測を行うこともできます。
品目の需要合計は、需要の従属構成部品と独立構成部品の合計です。たとえば、コンピュータ・モニターの需要は、直接(独立)需要と、パーソナル・コンピュータ・システムの販売から導出された需要(従属需要)の複合です。
次の表は、品目、計画比率に加えて、モデル部品構成表を展開した結果を記載したベース・モデル部品構成表のサンプルです。
| 部品構成表品目 | 計画比率 | 需要 | 展開計算 |
|---|---|---|---|
| . セダン | - | . 500 (予測) | - |
| .. タイヤ | ..100% | .. 500 | ..500 * 1 |
| ... 標準セット | .. 75% | ... 375 | ... 500 * 0.75 |
| ... 長寿命セット | .. 25% | ... 125 | ... 500 * 0.25 |
| .. シート | ..100% | .. 500 | .. 500 * 1 |
| ... 布 | ... 10% | ... 50 | ... 500 * 0.1 |
| ... レザー | ... 45% | ... 225 | ... 500 * 0.45 |
| ... ビニール・レザー | ... 45% | ... 225 | ... 500 * 0.45 |
| .. ルーフ・ラック | .. 35% | .. 175 | .. 500* 0.35 |
| ... ラゲッジ・スタイル | ... 60% | ... 105 | ... 175 * 0.6 |
| ... 自転車スタイル | ... 40% | ... 70 | ... 175 * 0.4 |
| .. 使用マニュアル | .. 100% | .. 500 | .. 500 * 1 |
Oracle e-Business SuiteからOracle Demantraへの受注構成データの移動
Oracle e-Business SuiteからOracle Demantraに移動するデータは次のとおりです。
品目マスター情報
オプション属性
Oracle e-Business SuiteからOracle Demantraへと受注構成データを移動するには、次の2段階のプロセスを使用します。
収集: 出荷および記帳履歴の収集プロセス
ダウンロード: EBS完全ダウンロードおよび統合プロファイルのインポートのプロセス
注意: BOMを収集するためには、MSD_DEM: 従属需要の計算プロファイルを「Yes」に設定する必要があります。
受注構成のレベル
受注構成情報は品目および組織ごとにソースに格納されており、すべてのディメンションの最下位レベルにダウンロードされます。たとえば、ある品目-組織の組合せの計画比率が50%である場合、他のすべての最下位レベル・ディメンションにおいて計画比率は50%と表示されます。
受注構成の構造には次のレベルがあります。
品目: 受注構成需要の品目最下位レベルです。
需要区分: 受注構成需要を分類する品目最下位レベルです。
ベース・モデル: (品目、親の)複数の組合せの需要を複数のルート・モデルに対して計画できるようにする、受注構成の品目最下位レベルです。
親品目: 複数の親のコンテキスト(品目、親)で同じ品目に対する需要を計画できるようにする、受注構成の品目最下位レベルです。親品目オブジェクトは部品構成表の一部ではありませんが、オプションの親はBOMで指定されます。
たとえば、次のような部品構成表の構造があるとします。
コンピュータ・パッケージA
. ラップトップA1
.. オプション区分ハードディスク
... ハードディスク120G
... ハードディスク150G
.. オプション区分プロセッサ
... プロセッサPentium 2GHz
... プロセッサAMD 2GHz
レベルのロードには次のエントリが含まれます。
| 品目(オプション) | 親(オプション区分) | ベース・モデル |
|---|---|---|
| ハードディスク120G | ハードディスク | コンピュータ・パッケージA |
| ハードディスク150G | ハードディスク | コンピュータ・パッケージA |
| プロセッサPentium 2GHz | プロセッサ | コンピュータ・パッケージA |
| AMD 2GHz | プロセッサ | コンピュータ・パッケージA |
受注構成のオプション
ベース・モデルに履歴がある場合、そのすべてのオプションがOracle Demantraにロードされます。
Oracle e-Business Suiteのオプション情報は品目および組織レベルによってディメンション化されます。この情報は、Oracle Demantraで保存および計画する際にサイトや需要区分といった他のディメンションに関連付ける必要があります。
受注構成の販売履歴
出荷および記帳履歴の収集プロセスには受注構成履歴が含まれます。
これにはプロファイル・オプション「MSD_DEM: 従属需要を含む」が使用されます。プロセスで受注構成の部品構成表を収集するには「Yes」に設定します。
このプロセスでは、出荷履歴タイム・スパン(または他の選択済シリーズのタイム・スパン)内のアクティブな部品構成表が収集されます。部品構成表の開始日は必須ですが、終了日は必須ではありません。
部品構成表に有効終了日があれば、部品構成表のその値により従属需要が計算されます。終了日がない場合、従属需要は予測の最終時間期間により計算されます。
オプションの履歴から履歴従属需要シリーズがロードされます。履歴従属需要にロードされるシリーズはOracle Demantraの独立需要履歴シリーズによって決まります。デフォルトは「出荷履歴 - 要求品目 - 出荷日」です。
注意: Oracle Demantraインプリメンテーション・ガイドのシステム・パラメータCTO_HISTORY_PERIODSに関する項を参照してください。
受注構成の収集のために使用できるシリーズは次のとおりです。
従属記帳 - 記帳品目 - 記帳日
従属記帳 - 要求品目 - 記帳日
従属記帳 - 記帳品目 - 要求日
従属記帳 - 要求品目 - 要求日
従属出荷 - 要求品目 - 納入日(デフォルト)
従属出荷 - 出荷品目 - 要求日
従属出荷 - 要求品目 - 要求日
収集パラメータ・ウィンドウで「Yes」とマークしたすべてのシリーズについて、オプションの出荷および記帳履歴が次のようにロードされます。
シリーズの名前は、マークされたシリーズの名前に「 - 従属需要」が付加されたものになります。たとえば「記帳履歴」シリーズを選択した場合、従属需要は「記帳履歴 - 従属需要」シリーズに格納されます。
例外はデフォルト・シリーズの場合で、この場合の従属需要は「履歴 - 従属需要」シリーズに格納されます。
このプロセスでは次の属性の構成品目のみが含まれます。
自動作成された構成: No。これにより構成品目が除外されます。
受注組立: Yes。
事前に指定された一般的な構成。
たとえば、次のような部品構成表の構造があるとします。
コンピュータ・パッケージA
. ラップトップA1
.. オプション区分ハードディスク
... ハードディスク120G
... ハードディスク150G
.. オプション区分プロセッサ
... プロセッサPentium 2GHz
... プロセッサAMD 2 GHz
販売履歴のロードには次のエントリが含まれます。
| 品目 | 親品目 | ベース・モデル | 日付 | 数量 |
|---|---|---|---|---|
| 120G | ハードディスク | コンピュータ・パッケージA | 1/1/2008 | 1 |
| プロセッサPentium 2 GHz | プロセッサ | コンピュータ・パッケージA | 1/1/2008 | 1 |
| ハードディスク | ラップトップA1 | コンピュータ・パッケージA | 1/1/2008 | 1 |
| プロセッサ | ラップトップA1 | コンピュータ・パッケージA | 1/1/2008 | 1 |
| ラップトップA1 | コンピュータ・パッケージA | コンピュータ・パッケージA | 1/1/2008 | 1 |
| コンピュータ・パッケージA | コンピュータ・パッケージA | コンピュータ・パッケージA | 1/1/2008 | 1 |
ワークシートでの部品構成表情報の表示
ワークシートに部品構成表ツリーを含めるには、次の手順を実行します。
「集計」タブで、「ベース・モデル」、「親品目」、「品目」の順に選択します。
「レイアウト」タブで、品目レベルを右クリックしてBOMツリーの表示を選択します。
システムでは、部品構成表ツリーをワークシートに表示するのに親レベルと子レベルを使用します。これらのレベルは「集計」タブに次のように表示されます。
CTO親
CTO子
BOMツリーの表示オプションが有効になっているワークシートでは、追加のビューを作成できます。どの追加のビューでも部品構成表ツリーは有効になります。逆に、BOMツリーの表示オプションをいずれかのビューで無効にすると、ワークシートのどのビューでも部品構成表ツリーは無効になります。
部品構成表ツリーに表示されているオプションまたはオプション区分である任意の品目にノートを追加できます。部品構成表ツリーのオプションまたはオプション区分で右クリックして「ノート」を選択すると、部品構成表ツリーが表示されるときにそのオプションまたはオプション区分のノートが表示されます。
品目が部品構成表ツリー形式で表示されていない場合(たとえば、すべてのベース・モデルにまたがる品目の従属需要および独立需要)、部品構成表ツリーのその品目に割り当てられているすべてのノートが表示されます。
どの表示書式においても、表示は次のようになります。
独立需要が常に含まれます。
部品構成表の親の需要関係に依存する計算である場合、従属需要が含まれます。
BOMツリーの表示を選択すると、部品構成表が階層形式で表示されます。
BOMツリーの表示を選択せず、クロス集計の品目も選択しなかった場合、すべてのレベルがフラットになったリストとして部品構成表が表示されます。
BOMツリーの表示を選択せず、クロス集計に品目と親品目の両方がある場合、部品構成表のマルチ・レベルの再帰がない通常のクロス集計が表示されます。
情報をレベルごとにグループ化して表示する場合、CTOレベルに新しいレベルを追加できます。たとえば、製品ファミリ・サーバーのベース・モデルのすべてのBOMを表示する場合に新しいレベルを追加でき、実装時に「BM製品ファミリ」という名前のCTOレベルを作成してBOMツリーの右側に配置できます(ベース・モデルの製品ファミリ・サーバーへの関連付けも実装タスクです)。
製品ファミリ・レベルの作成
レベルは通常、関連付けられているレベル値を表示するといった情報表示のためにBOMツリーの右側に配置されます。これは、ビジネス・モデラーでレベルにシリーズを作成することで実現できます。
ビジネス・モデラーで、「シリーズ」アイコンをクリックします。
「新規」アイコンをクリックします。
一般プロパティ・タブで次のように入力します。
シリーズ名を入力
編集＝不可
プロパティの表示タブで次のように入力します。
表のみ
要約なし
データ・プロパティ・タブで次のように入力します。
データ表 = レベル。例:
<レベル>製品ファミリ
集計関数 = MIN
式のプロパティ・タブで次のように入力します。
サーバー式 = MIN関数の関連表を選択。例:
min (t_ep_ebs_prod_family.ebs_prod_fmly_desc)
「保存」をクリックします。
ワークシートでの計画比率の編集
オプションの区分と品目の組合せが複数のベース・モデルの構成の一部となっている場合があります。
計画比率の初期ダウンロード後は、複数のベース・モデルに存在するオプションの区分と品目の組合せの計画比率は同じになります。
複数のベース・モデルに存在するオプションの区分と品目の組合せをワークシートを使用して編集する場合、ワークシートのディメンションとしてベース・モデルが含まれているかそれとも除外されているかによって結果として得られる計画比率が異なる場合があります。
注意: Oracle Demantraインプリメンテーション・ガイドのシステム・パラメータCTO_Enable_Worksheet_Calculationsに関する項を参照してください。
この例は、計画比率を最初にダウンロードした後の2種類のCPUのベース・モデルを示しています。
| 部品構成表品目 | 計画比率 | 部品構成表品目 | 計画比率 |
|---|---|---|---|
| . CPU 1 (モデル) | - | . CPU 2 (モデル) | - |
| .. ドライブ(オプション区分) | ..100% | .. ドライブ(オプション区分) | 100% |
| ... ハード・ドライブ120G | .. 40% | ... ハード・ドライブ120G | ... 40% |
| ... ハード・ドライブ220G | .. 60% | ... ハード・ドライブ220G | ... 60% |
ベース・モデルがワークシート・レベルである場合:
次の例を見てみましょう。
ワークシート・レベルはベース・モデル、オプション区分および品目です。
モデルCPU 1 > オプション区分ドライブ > ハード・ドライブ220Gの計画比率を60%から80%に変更します。
| 部品構成表品目 | 計画比率 |
|---|---|
| . CPU 1 (モデル) | - |
| .. ドライブ(オプション区分) | ..120% |
| ... ハード・ドライブ120G | .. 40% |
| ... ハード・ドライブ220G | .. 80% |
ベース・モデルがワークシート・レベルであるこの例を引き続き見ていきましょう。
ベース・モデルがワークシートに含まれているレベルであるため、モデルCPU 2 > オプション区分ドライブ > ハード・ドライブ220Gの計画比率は60%のままです。
オプションの区分と品目の組合せをOracle Advanced Supply Chain Planningにエクスポートするために、Oracle Demantraでは複数の計画比率の平均を算出し、その平均をエクスポートします。この場合は、オプション区分ドライブ > ハード・ドライブ220Gについては70%をエクスポートします[(80 + 60) / 2 = 140 / 2]。
| 部品構成表品目 | 計画比率 | 部品構成表品目 | 計画比率 |
|---|---|---|---|
| . CPU 1 (モデル) | - | . CPU 2 (モデル) | - |
| .. ドライブ(オプション区分) | ..120% | .. ドライブ(オプション区分) | 100% |
| ... ハード・ドライブ120G | .. 40% | ... ハード・ドライブ120G | ... 40% |
| ... ハード・ドライブ220G | .. 80% | ... ハード・ドライブ220G | ... 60% |
ベース・モデルがワークシート・レベルではない場合:
次の例を見てみましょう。
ワークシート・レベルはオプション区分および品目です。
オプション区分ドライブ > ハード・ドライブ220Gの計画比率を60%から80%に変更します。
| 部品構成表品目 | 計画比率 |
|---|---|
| .. ドライブ(オプション区分) | ..120% |
| ... ハード・ドライブ120G | .. 40% |
| ... ハード・ドライブ220G | .. 80% |
ベース・モデルがワークシート・レベルではないこの例を引き続き見ていきましょう。
ベース・モデルがワークシートに含まれているレベルではないため、モデルCPU 2 > オプション区分ドライブ > ハード・ドライブ220Gの計画比率も80%に変わります。
オプションの区分と品目の組合せをOracle Advanced Supply Chain Planningにエクスポートするために、Oracle Demantraでは共通の計画比率をエクスポートします。この場合は、オプション区分ドライブ > ハード・ドライブ220Gについては80%をエクスポートします。
| 部品構成表品目 | 計画比率 | 部品構成表品目 | 計画比率 |
|---|---|---|---|
| . CPU 1 (モデル) | - | . CPU 1 (モデル) | - |
| .. ドライブ(オプション区分) | ..120% | .. ドライブ(オプション区分) | 100% |
| ... ハード・ドライブ120G | .. 40% | ... ハード・ドライブ120G | ... 40% |
| ... ハード・ドライブ220G | .. 80% | ... ハード・ドライブ220G | ... 80% |
シミュレーション
シミュレーションを実行することで、すべてのデータではなく現在のワークシートのみに基づいてだいたいの予測を取得できます。
モデルやオプションの履歴を上書きしてシミュレーションを確定するなどして、予測に影響する従属需要 - 履歴に変更を加えた場合、シミュレーションのプロセスでは次のようなことが行われます。
新しい予測の生成
計画比率の再計算
影響を受けたセルの従属需要の再計算
注意: この動作が発生するためには「計画比率選択」が「履歴」である必要があります。
モデルやオプションの履歴を上書きしてシミュレーションを確定するなどして、予測に影響する従属需要 - 既存に変更を加えた場合、シミュレーションのプロセスでは次のようなことが行われます。
新しい予測の生成
計画比率はそのまま保持
影響を受けたセルの従属需要の再計算
注意: この動作が発生するためには「計画比率選択」が「既存」である必要があります。
上書き
計画比率、従属需要および独立需要(予測)に変更を加えるには、これら3つのシリーズのいずれかを対応する上書きシリーズ(計画比率上書きなど)で上書きします。
変更は構成表構造のどの深さのレベルに対しても行えます。この変更は構成表構造全体に伝播され、オプション区分が変更された場合はその変更がオプション区分の子に伝播されます。手動でさらに変更を加える必要はありません。
計画比率および従属需要の設定
e-Business Suiteに対して、受注構成構造、需要および履歴を収集するように指示する必要があります。
使用する計画比率を指定できます。指定可能なオプションは「既存」(ソースからダウンロード)または「履歴」(Demantraで計算)です。
オプションの履歴に基づいて計画比率を計算する際は、使用する履歴期間の数を指定できます。
従属需要を計算して計画比率を導出する場所を指定できます。指定可能なオプションは各組織、またはグローバルです。
詳細は、Oracle Demantraインプリメンテーション・ガイドの受注構成の設定に関する項を参照してください。
販売履歴オプションに基づく計画比率の計算
履歴計画比率は時間によって変化せず、すべての予測期間にわたって同じ計画比率が使用されます。
たとえば、履歴に基づく2009年1月と2009年2月の予測があるとすると、2009年1月と2009年2月のオプションの従属需要の計算には同じ予測比率が使用されます。
計画比率 - 履歴 =
Average(option's history/parent's history for CTO_HISTORY_PERIODS). このプロセスでは、品目のBOM有効開始日より前または品目のBOM有効終了日より後には計画比率は計算されません。
部品構成表の最下位レベルまで、すべての有効な品目の計画比率が計算されます。
計画比率に基づく従属需要の計算
オプションおよび品目の従属需要計算は、ベース・モデルの情報に基づきます。
これは次のステージで発生します。
予測エンジン・プロセスがベース・モデルを生成した後
ベース・モデル情報を変更したとき
この計算では、中間レベルのデータの変更がそのレベルのすべての子に伝播されます。
従属需要 - 既存 =
Plng Pct- Existing * Immediate parent forecast従属需要 - 履歴 =
Plng Pct- History * Immediate parent forecast予測従属需要 =
Final Plng Pct * Immediate parent forecast最終予測従属需要 =
If there is a value in Forecast Dependent Demand Override, it is the Forecast Dependent Demand Override value. Otherwise, it is the value of Forecast Dependent Demand.予測の計算
グローバル予測の場合:
計画比率をグローバル・レベルで計算します。
親品目またはベース・モデルの販売履歴をすべての組織にわたって集計します。
計画比率を全組織レベルで計算します。
すべての組織に対して同じ計画比率を使用します。
1つの組織の従属需要または計画比率がワークシートで変更されると、他のすべての組織の需要に影響します。
製品ファミリ予測の場合:
製品ファミリ需要を使用して統計製品ファミリ予測を生成します。
製品ファミリ予測をメンバー品目予測に割り当てます。
受注構成MAPE計算
シリーズMAPE CTOでは、コンセンサス需要合計の精度統計を計算するMAPE CTOプロシージャの結果を保持します。これにより、安全在庫を計算するために在庫最適化で必要となる情報が得られます。この計算は次のとおりです。
sum(abs(Total History ? Archived Consensus Total Demand))/sum(History)where- Total History = History + Final Forecast Dependent Demand for the 13 week period of the archived forecast- Consensus Total Demand = Independent Demand + Dependent Demand関連項目
EBSおよび非Oracleシステムとの統合の詳細は、Oracle Demantraインプリメンテーション・ガイドの受注構成の設定に関する項を参照してください。
サービス・パーツ計画
修理サービス工程では、在庫予算およびサービス・レベル・ターゲットとの整合性をとりつつ、正しい部品が正しい時に正しい(使用可能な)条件で正しい場所に存在することがサービス・パーツ計画システムにより保証されるようにする必要があります。
サービス・パーツ在庫管理は製品在庫管理とは異なります。交替および断続的な需要といった特別なサービス・パーツ状況を処理するように設計された機能が必要なためです。
Oracle Service Parts Planningソリューションでは、次の予測モデルをサポートしています。
従来
需要計画システムではサービス・パーツ計画に対する、そして実装されている場合は在庫最適化計画に対する需要計画入力となる需要予測を生成します。需要計画システムではまた、サービス・パーツ計画への供給計画入力となる返品予測も生成します。
インライン
サービス・パーツ計画では、Oracle Demantra Demand Managementの機能を使用してサービス・パーツ需要を生成します。
いずれのモードでも、予測のベースには使用履歴と出荷履歴のどちらでも使用できます。
新製品投入の場合、または信頼できる基準となる履歴が十分に存在しない類似の状況では、インライン・モードにより、品目の投入ベース移入および平均故障率に基づいて予測できます。
このドキュメントでは、Demantraでサービス・パーツ予測を生成し、Oracle Service Parts Planningまたは他のレガシー・アプリケーションで使用するというインラインのシナリオについて説明します。
Oracle Service Parts PlanningやOracle Field Service Spares Management、Oracle Depot Repairの詳細は、該当するOracle製品のドキュメントを参照してください。
サービス・パーツ予測
Demantraではサービス・パーツの需要を2つの方法を使用して予測します。1つの方法では分析モデルを使用し、もう1つの方法では導入ベース・データと故障率を使用して計算されます。Demantraでは予測が両方の方法を使用して生成され、過去の経験、産業固有の知識、または他の情報に基づいて適切な予測を選択できます。
サービス・パーツ固有の故障率を組織の予測導入ベースに適用すると、サービス・パーツの将来の需要を予測することが可能になります。
故障率
故障率は、完成品でサポートされている単位とその単位に対してサービスを提供するために使用されるサービス・パーツの実際の数量の比較に基づいています。シード済のプロセスでは、サポートされているベース・モデルの数および使用量の比率が計算されます。このプロセスの結果が故障率です。
これらの値を計算するレベルは、ビジネス要件によって変動することがあり、実装の際に構成できます。故障率は非常に細かい粒度レベルで計算できます。これにより、特定のスペアおよび場所の部品使用量を厳密に反映した計画比率が得られます。しかしこの方法は、本質的に部品の使用量が断続的であるため、時間とともに需要の大きな変動の影響を受けやすいという面もあります。また、故障率をより集計したレベルで計算することもできます。この場合、生成される故障率はより一般的なものになりますが、変動の影響は受けにくくなります。
集計で生成された場合、基本となるすべての組合せには同じ故障率が割り当てられます。
故障率計算を構成する方法の詳細は、Oracle Demantraインプリメンテーション・ガイドを参照してください。
プロセスの概要
次の例は、一般的なサービス・パーツ予測サイクルを示しています。
サービス品目や使用履歴、導入ベース詳細、詳細といったデータがソース・システム(Oracle Service Parts Planningなど)からDemantraにインポートされます。
Demantra分析エンジンによりスペア/組織レベルで予測が生成され、プロジェクトの導入ベース情報および故障率に基づいて別の予測が計算されます。
Demantraにより新しい予測値が次のシリーズに格納されます。
SPFベースライン予測
SPF計算済予測
前述のシリーズに格納された値を使用して、Demantraにより自動的に次のシリーズの値が計算されます。
SPF予測MAPE (サンプル内)
SPF予測MAPE (サンプル外)
SPF予測ボラティリティ
SPF平均需要
これらのシリーズについては付録A「サービス・パーツ予測シリーズ」で説明されています。
注意: 予測精度メジャーは任意の集計レベルで表示できますが、デフォルトではスペア/組織レベルで計算されます。ワークシートにおいてこのレベルより上位で表示すると、選択したそのレベルで値が集計されます。
事前定義済またはカスタムのワークシートを使用して、需要アナリストはこれらのシリーズの値をレビューし、導入ベースおよび故障率の値を分析して、必要であれば調整を加え、それからシミュレーションを実行して別のシナリオをモデル化します。必要なシナリオが得られたら、ユーザーは変更をワークシートに保存してシミュレーション結果を確定します。
このプロセスにおいて、次のシナリオが上書きされることがあります。
SPF品目使用量またはSPF品目出荷(履歴需要)
SPF故障率%
SPF導入ベース
SPF計算済予測
SPFベースライン予測
故障率または導入ベースへの変更はすぐに改訂SPF計算済予測値に反映されます。
オプションで、アナリストは「SPF予測方法」シリーズのデフォルト値を変更できます。この設定は、どの予測により「SPF最終予測」シリーズが移入され、最終的にOracle Service Parts Planning (SPP)などのダウンストリーム・アプリケーションにエクスポートされるかを制御します。
アナリストはワークシートで加えた増分変更を手動でDemantraステージング表に、そしてそこからサービス・パーツ計画にアップロードできます。これを行うには、ワークシート内からメソッドを起動します。この方法の詳細は、Oracle Demantraインプリメンテーション・ガイドを参照してください。
望ましい(最終)予測および他のメトリックはワークフローを使用してDemantraステージング表にエクスポートされます。
外部システムの管理者は必要なプロセスを実行して最終予測およびメトリックをDemantraステージング表から外部システムのデータベース表にインポートします。
この予測とメトリックは外部システムで、たとえば例外をトリガーするために、または他のカスタム・プロセスへの入力として使用されます。
サービス・パーツ予測ワークシートの詳細は、「サービス・パーツ予測(SPF)ワークシート」を参照してください。
予測エンジンを実行する際にフル・バッチ・エンジンを実行する必要がない場合があります。たとえば、環境が大きすぎると、週末だけでは使用可能な予測の組合せすべてを処理できない場合があります。あるいは、予測サイクルごとにすべての組合せの予測をリフレッシュする必要がない場合もあります。
サブセット予測では、フィルタされた組合せサブセットに対してバッチ予測を生成する機能を提供します。この実行によって需要予測のバージョニングを進むことはなく、指定されたサブセットの最新の予測が上書きされるのみです。これはシミュレーションを実行して確定するのと同じですが、ワークシートを開く必要がなく、処理の平行化の恩恵を受けることができます。予測のバージョニングを行うにはフル・バッチ実行が必要となるため、サブセット予測によってフル・バッチ実行が完全に置き換えられることはありません。
サブセット予測の詳細は、Oracle Demantra分析エンジン・ガイドの予測モデルに関する項を参照してください。
Copyright © 2014, Oracle and/or its affiliates. All rights reserved.