Oracle Service Parts Planningインプリメンテーションおよびユーザー・ガイド リリース12.1 B70972-01 | ![]() 目次 | ![]() 前へ | ![]() 次へ |
この章では、次のトピックを説明します。
ERP(Enterprise Resources Planning)または需要計画システムで、あるいはSPP内で生成されたスペア部品の予測を需要計画として計画に入力できます。SPP内部で予測を生成することをインライン予測と言います。
次のトピックでインライン予測について説明しています。
使用量パターン、資産母集団、サービス製品ライフ・サイクル、故障率など、多くの変数が需要に影響を及ぼします。Oracle Service Parts Planningは次のデータ・ストリームに基づいた予測をサポートしています。
スペア部品出荷履歴
スペア部品使用履歴
スペア部品返品履歴
スペア製品返品履歴
製品母集団と故障率
* 予測レベル
組織レベルとゾーン・レベルの両方で品目に予測ポリシーが割り当てられている場合は、ローカル予測とグローバル予測の両方を生成します。1つのサービス操作で現場技術者による修理サービス(現場での部品使用量の収集)と内部デポでの修理サービス(内部修理オーダーに対する出庫履歴の収集)が提供される場合に、この方法を使用して完全なデータに基づいた予測を生成します。
どの履歴データ・ストリームを予測ルールの予測基準として使用するかを指定します。計画では、計画オプションに含まれていない組織からの社内受注(その組織へのアウトバウンド出荷)および現場技術者組織への出荷は、出荷履歴と見なされます。そのような出荷には、通常、物流組織から現場組織へのアウトバウンド出荷、または該当する場合は、社外顧客への直接の出荷が含まれます。
カウントの重複を避けるために、履歴ストリームには現場技術者組織への出荷は含まれますが、物流組織への出荷は含まれません。計画の範囲が中央倉庫に限られている場合は、中央倉庫からのすべてのアウトバウンド出荷を履歴基準に含める必要があります。
SPPでは、出荷基準の予測を目的として2つのデータ・ストリームを収集します。
出荷先組織が現場技術者組織である社内受注のアウトバウンド出荷。現場技術者組織は「収集」設定ウィンドウで指定します。出荷先が現場組織でないアウトバウンド出荷を履歴に含めることはできません。
次の情報は履歴の一部として使用されます。
品目、出荷日、出荷元組織、出荷先組織、出荷数量および単位(UOM)。
社内受注(ISO)およびそれに対応する社内購買依頼を収集します。ISOには出荷先組織がありません。「出荷先」では外部事業所を指定します。したがって、ISOの出荷先組織を決定するには、社内購買依頼にリンクする必要があります。社内購買依頼を作成した組織が出荷先組織になります。
データ・ストリームの定義の詳細
ソース・タイプ: ERP
データのタイプ: 数量
ディメンション・レベル
製品: 品目
出荷元: 組織
出荷先: 組織(出荷元組織に基づいたローカル予測)
地理情報: なし
時刻: 日付レベルのみ
計画オプションで技術者組織が計画組織に指名されていないことを確認してください。計画組織は物流組織と見なされ、対応する履歴は予測を目的とする処理で無視されます。
同様に、履歴が収集されている物流組織が計画で計画組織になっていない場合も、その履歴データは無視されます。
たとえば、中央配送センターが現場技術者組織へのアウトバウンド出荷を行い、その履歴が収集されたとします。しかし、計画オプションでは、中央配送センターが計画組織になっていません。その場合、中央配送センターの対応する履歴は、予測を目的とする処理で考慮されません。
次の情報は履歴の一部として使用されます。
品目、組織、出荷日、出荷数量、単位
データ・ストリームの定義の詳細
ソース・タイプ: ERP
データのタイプ: 数量
ディメンション・レベル
製品: 品目
出荷元: 組織
出荷先: 組織
時刻: 日付レベルのみ
Oracle Spares Management Debrief処理の一部として取得された資材使用量履歴データは、技術者組織用の将来の部品所要量の予測に使用されます。技術者組織のスペア部品品目使用履歴はゾーン・レベルで計算されます。ゾーンは、フィールド・サービスでの使用が発生する技術者トランク在庫(または保管場所)に結び付けられた場所に基づいて決まります。
供給計画では、これらの予測がグローバル予測と見なされます。その予測を適切な補充組織にプッシュするためのグローバル・ソース・ルールを指定します。
サービス部品使用履歴は、Spares Management Debrief処理で作成されたOracle Field Service使用取引から収集されます。
この処理では、次の情報を収集します。
交換されたサービス部品(品目ID)
交換日
交換数量
顧客事業所(ゾーン・レベル)
データ・ストリームの定義の詳細
ソース・タイプ: ERP
フィールド・サービス: Oracle Spares Managementの報告処理で作成されたフィールド・サービス使用取引のみを収集します。
データのタイプ: 数量
ディメンション・レベル
製品: 品目
出荷元: 組織
出荷先: ゾーン
時刻ディメンション: 日付レベルのみ
デポ組織での修理作業指示に対する構成部品出庫履歴データを収集することによって、デポ修理組織での部品消費履歴に基づいてスペア所要量予測を行うこともできます。このような予測はデポ組織レベルで生成されます。
サービス部品使用履歴は、Oracle Depot Repairの修理オーダー用の資材所要量またはJTF(Java Technology Framework)タスクから収集されます。
次の情報が収集されます。
交換されたサービス部品(品目ID)
交換日
交換数量
顧客事業所(ゾーン・レベル)
データ・ストリームの定義の詳細
ソース・タイプ: ERP
デポ修理: 修理製造オーダーの資材所要量および製造オーダー数量を収集します。修理製造オーダーはOracle Depot Repairの修理オーダーに基づいてWIP(Work in Process)で作成される非標準ショップ型製造オーダーです。JTFタスクからも資材所要量を収集します。
データのタイプ: 数量
ディメンション・レベル
製品: 品目
出荷元: 組織
出荷先: 組織レベル
時刻ディメンション: 日付レベルのみ
返品を計算する基本的な方法には次のものがあります。
返品基準の予測では、サービス部品および製品の返品履歴をOracle Field ServiceおよびOrder ManagementのRMAから取得します。その情報が将来の返品を予測するときの基準になります。したがって、返品全体の予測は次の項目に依存します。
現場技術者からのサービス部品の返品
RMA処理を介した顧客からのサービス部品の直接の返品
RMA処理を介した顧客からの製品の直接の返品
フィールド・サービス返品は、グローバル返品としてゾーン・レベルで計画プロセスに供給されます。計画担当は、返品をソース・ルールに割り当てて、ビジネス・プロセスに従ってフィールド・サービス部品返品予測を適切な返品組織にプッシュすることができます。
フィールド・サービス報告処理で作成されたフィールド・サービス回収取引のみが収集されます。
データ・ストリームの定義の詳細:
ソース・タイプ: ERP
データのタイプ: 数量
フィールド・サービス表から次の情報を収集します。
返品された障害品サービス部品(品目ID)
返品日
返品数量
顧客事業所(ゾーン・レベル)
ディメンション・レベル
製品: 品目
出荷元: 組織レベル
出荷先: ゾーン・レベル
時刻: 日付レベルのみ
RMA処理を介してサービス部品を直接返品することもできます。Order ManagementのRMA処理を介して顧客から返品された障害品スペア部品は、修理組織で計画プロセスに入力されます。
「包括RMAタイプ」フィールドを使用して、収集するRMAのタイプを選択します。
すべて(デフォルト): すべてのRMAタイプの返品が収集されます。
交換、受入あり、クレジットなし、受入およびクレジットあり、修理RMA
「クレジットのみのRMA」と呼ばれるタイプのRMAは収集されません。
データ・ストリームの定義の詳細:
ソース・タイプ: ERP
データのタイプ: 数量
次のデータは、直接返品の一部としてOracle Order Managementから収集されます。
返品された障害品サービス部品(品目ID)
組織
顧客事業所
返品日(RMA作成日)
返品数量
ディメンション・レベル
製品: 品目
出荷元: 組織(ローカル予測)
出荷先: 組織(ローカル予測)
時刻: 日付レベルのみ
注意: 返品受注は明細タイプ返品で数量がマイナスの受注です。
多くの場合、顧客はOrder ManagementのRMA処理を介して製品を直接返品します。これらの製品を修理のために分解したり製品から部品を取り外したりすると、障害品サービス部品が発生します。この障害品部品のストリームは返品の予測で考慮されます。1つの製品から生み出されるサービス部品の数量は、特定の製品に含まれているサービス部品の平均故障率に依存します。製品とサービス部品の組合せの故障率は、導入ベース、故障率、除・売却率の設定の項で説明している手順で求めます。
製品返品履歴が収集され、予測されます。サービス部品に固有の故障率を予測製品返品に掛けて、予測サービス部品返品を求めます。特定のサービス部品の返品合計は、製品とサービス部品との関係が確立されている、対応する製品から得られたすべての返品の合計に等しくなります。
ソリューションの概要
ソリューションは次のコンポーネントから構成されます。
製品返品履歴の収集 – Order Managementオーダー・タイプ:RMA。
履歴に基づいた将来の製品返品の予測。予測方法は、製品に関連付けられた予測ルールで指定されます。
予測製品返品に故障率を掛けてサービス部品返品を予測します。
バケット (t) 内のサービス部品 (i) の返品 = SUMj=1,n (バケット (t) 内の製品の返品 (j) * 故障率(i,j) )
ただし、
(i)は製品(j)に属するサービス部品
n はサービス関係が有効になっている製品の数(「設定」>「製品母集団予測パラメータ・フォーム」で定義される)
前提:
障害品サービス部品は返品された製品のバケットと同じバケット内で使用できるものとします。実際は、製品の返品からサービス部品が使用可能になるまで遅延があります。しかし、計算を単純化するために、これらのイベントが同時に発生するものとします。
「使用量/出荷/返品」タブで、予測ルールの一部として次の2つの主要なコンポーネントを指定します。
「履歴基準の製品返品」を選択します。
将来の製品返品を予測するための予測方法や範囲などの予測パラメータを指定します。
「包括RMAタイプ」フィールドを使用して収集するRMAのタイプを選択します。
すべて(デフォルト): すべてのRMAタイプの返品が収集されます。
交換、受入あり、クレジットなし、受入およびクレジットあり、修理RMA
「クレジットのみのRMA」と呼ばれるタイプのRMAは収集されません。
データ・ストリームの定義の詳細
ソース・タイプ: ERP
データのタイプ: 数量
ディメンション・レベル
製品: 品目
出荷元: 組織
出荷先: 組織
時刻: 日付レベルのみ
サービス関係で製品として定義されている品目の返品履歴が収集されており、予測ルールで製品返品が履歴基準に指定されている場合は、製品返品に固有の計算が実行されます。サービス部品の返品履歴が収集されている場合は、品目返品履歴が予測されます。
返品の予測は、現場技術者からの返品、直接のサービス部品返品、直接の製品返品から生じた返品から構成されます。ただし、これらのストリームの内訳はユーザーからは見えません。ユーザーには、すべての返品ソースを集計した1つの数字しか見えません。製品母集団基準の返品(返品率予測)は別の行に表示されます。
サービス部品の故障率が製品全体の母集団とともに判明している場合は、その情報に基づいてサービス部品の需要と供給を予測できます。製品全体の母集団は、現在のサービス対象製品と、これからサービス対象になる将来のまたは予定されている製品から構成されます。製品の母集団を正確に把握するには、除・売却(製品がサービス対象から外されること)も考慮する必要があります。故障率は、通常、経過期間に依存し、製品のライフサイクル・ステージによって異なります。
主要なコンポーネント
製品母集団基準の予測の主要なコンポーネントを次に示します。
Oracle Install Base履歴: Oracle Installed Baseから収集された期間別Install Base履歴が現在の導入ベースと故障率の計算に使用されます。
現在のInstall Base母集団: この値は現在導入されている有効な製品の合計から構成されます。この情報は次のどちらかの方法を使用して取得されます。
ユーザー指定: 現在の導入ベースの値をユーザーが入力します。または、
Oracle Install Baseから計算: この値は、収集されたOracle Install Base母集団履歴ストリームに基づいて計算されます。
予測製品母集団: この母集団は導入ベース情報に基づいており、次の式に従って計算されます。
導入ベース (t) = {導入ベース (t-1) + [販売予測 (t) * サービス市場占有率] * 期間残存率}
ただし、導入ベース (t) は現在の導入ベース値を表します。
故障率: この値は製品の母集団の平均期間故障率を表します。製品とサービス部品の組合せの平均(時間に依存しない)故障率を指定します。
サービス部品の予測需要の計算: 予測母集団と故障率が判明すれば、一定期間(t)のサービス部品の需要を予測できます。
サービス部品の予測需要 (i,t) = SUMj=1,n (予測製品母集団 (j,t) * 故障率 (i,j))
ただし、
iは製品jで使用されているサービス部品
nはサービス部品iを使用している製品の総数
Oracle Install Baseを使用して顧客サイトで製品と資産を追跡し、現場のサービス可能製品の総数を求めることができます。正確な導入ベースの数を求めるには、製品の除・売却を考慮する必要があります。
年 | 2003 | 2004 | 2005 | 2006 | 2007 |
---|---|---|---|---|---|
新規導入ベース | 100 | 120 | 110 | 125 | 120 |
除・売却 | 0 | 0 | 0 | 50 | 100 |
純導入ベース | 100 | 120 | 110 | 75 | 20 |
データ・ストリームの定義
名称: Install Base履歴
ソース・タイプ: ERP
データのタイプ: 数量
割当: 許可されていません
ディメンション・レベル
製品: 品目
出荷元: 適用不可
地理情報: 適用不可
時刻: 2つの日付 — 導入日と最終有効日が存在します
販売チャネル、営業担当およびユーザー定義ディメンション: 適用不可
次の情報がOracle Install Base表から収集されます。
製品
所有者パーティID
導入日
最終有効日(この日付で廃止されます)
数量
導入ベースの収集は外部の顧客サイトでのみ行われます。顧客名(導入パラメータで定義されている「内部」ではない「所有者パーティID」)が製品に関連付けられている場合、その製品は外部導入ベースの一部になります。さらに、導入ベースの日付が空白またはnullの場合は、製品が大規模な修理を目的として返品されているか、恒久的に返品されている可能性があります。そのような行は無視されます。
導入ベースを追跡するためにロット管理が有効になっている場合は、数量が2以上の可能性があります。ロット内の製品(品目インスタンス)が除・売却されている場合は、除・売却された製品のみが最終有効日を持つようにInstall Baseでロットが分割されます。前述のデータ例では、行2、3、4がロット数量5を表しており、そのうち2つが除・売却されています。
有効な導入ベースと除・売却された導入ベースの両方が収集されますが、除・売却された導入ベースは除外されます。次の表はデータ行が除外されているかどうかを示しています。
製品 | 所有者パーティID | 導入日 | 最終有効日 | 数量 | 除外されているか? (YesまたはNo) | |
---|---|---|---|---|---|---|
1. | プリンタAT | Zinc Inc. | 2007年4月1日 | なし | 7 | No |
2. | プリンタAT | Zinc Inc. | 2006年1月4日 | 2007年1月31日 | 1 | No |
3. | プリンタAT | Zinc Inc. | 2006年1月4日 | 2006年12月10日 | 1 | Yes。履歴開始日の前に製品が除・売却されています。 |
4. | プリンタAT | Zinc Inc. | 2007年1月10日 | なし | 3 | No |
5. | プリンタAT | Red Inc. | 2007年4月7日 | なし | 5 | No |
6. | プリンタAT | 内部 | 2007年1月5日 | なし | 2 | Yes。外部ではありません。 |
7. | プリンタAT | Red Inc. | なし | なし | 1 | Yes。返品された可能性があります。 |
8. | プリンタAT | Red Inc. | 2007年2月15日 | なし | 5 | No |
最後に、需要予測分析ビュー に表示される情報が製品レベルで集計され、計画オプションで指定された予測バケット・サイズに基づいてバケット設定されます。例:
前述の履歴情報は次のように月単位のバケットに要約されます。
製品 | 数量 | 期間 | コメント |
---|---|---|---|
プリンタAT | 4 | 2007年1月 | 製品は期間終了時にただちに除・売却されると想定されています。 |
プリンタAT | 8 | 2007年2月 | |
プリンタAT | 8 | 2007年3月 | 新規導入または除・売却がなかったため、2月と同じ |
プリンタAT | 20 | 2007年4月 | |
プリンタAT | 20 | 2007年5月 |
需要予測分析ビューを参照してください。
収集パラメータ
Install Base履歴を収集するかどうかを柔軟に指定できるように、Install Base履歴パラメータが値リスト値「Yes」または「No」とともに「収集」ウィンドウに表示されます。
現在の導入ベースの母集団
現在の導入ベースの母集団は予測導入ベースの基準の役割を果たします。Oracle Install Base情報が使用できる場合、この値は次の式で計算されます。
現在の導入ベース= (現在までの導入ベースの母集団の合計 - 現在までの除・売却数)
年 | 2001 | 2002 | 2003 | 2004 | 2005 | 合計 |
---|---|---|---|---|---|---|
新規導入ベース | 100 | 120 | 110 | 125 | 120 | 575 |
除・売却 | 0 | 0 | 0 | 50 | 100 | 150 |
この例の現在の導入ベースは(575 – 150) = 425に等しくなります。
Oracle Install Base情報が利用できない場合は、ユーザー・インタフェースを介して直接、または一括アップロード機能を利用して、この情報を入力できます。
予測製品母集団
予測製品母集団は、通常、Install Base履歴または現在の導入ベースに販売予測を加算した値に基づいて決まります。
Install Base履歴に基づく製品の母集団の予測
Install Base履歴を使用して製品の母集団を予測する方法を選択できます。その場合は、適切な予測方法を選択し、予測の対象になる範囲を設定します。
販売予測に基づいた製品の母集団の予測
すべての製品売上がサービス契約に結び付くわけではないため、販売予測を調整してサービス市場占有率の概算値を求めることができます。販売予測を調整するためのサービス調整ファクタと呼ばれる係数が用意されています。予測製品母集団は次の式で計算されます。
導入ベース (t) = [導入ベース (t–1) + [販売予測 (t) * サービス調整ファクタ] * (1 -除・売却率)
注意: 導入ベース(t = 0)は現在の導入ベースと等しくなります。
販売予測の概算
販売予測が利用可能であれば、それを直接使用できます。次の2つの選択肢があります。
フラット・ファイル・ロード(需要計画として提示)
需要計画とERP予測
オプションで、予測母集団を直接入力したり(値が既知の場合)、サービス調整ファクタを1に設定(または空白のままに)したり、除・売却率をゼロに設定(または空白のままに)したりできます。
販売予測が利用できない場合は、販売予測を生成し、それを予測製品母集団の計算に使用できます。この方法で生成される販売予測は予測製品母集団の計算のみを目的としており、ユーザー・インタフェースで見たり、他の目的に使用したりすることはできません。
収集パラメータの一部として受注記帳履歴と出荷履歴を収集できます。データはグローバル・パラメータで指定された範囲にわたって日レベルで収集されます。
次の受注データが収集されます。
品目
インスタンスと組織
記帳日
出荷日
数量
単位
販売予測は指定された予測パラメータに基づいて行われます。履歴範囲、予測範囲、カレンダおよびバケットを「予測ルール」ウィンドウの「範囲詳細」タブから選択します。記帳履歴または販売履歴のどちらを使用するかを指定できます。予測エンジンが適切な日付を考慮します。
予測は組織レベルでのみ行われます(ローカル予測)。システムがローカル予測を生成すると、情報がグローバル品目レベルで集計されます。つまり、特定の品目のすべての組織レベルの数量が加算されます。グローバル・レベルの販売予測が確定すると、それ以降の計算によって導入ベースが予測されます。
耐用期間が経過すると製品は除・売却され、導入ベースから除外されます。したがって、予測母集団を正確に求めるには、除・売却率を考慮に入れる必要があります。平均期間除・売却率を記録することはビジネス慣習として一般的です。この値は、通常、特定の期間(またはバケット)中に除・売却される製品全体の母集団の比率で表します。
製品母集団予測の期間バケット・レベルと同じ期間バケット・レベルで除・売却率を入力する必要があります。除・売却率は時間に依存しません。これは、予測範囲全体に対して同じ率が適用されることを意味しています。
例:
製品: プリンタA
サービス調整ファクタ: 60%
除・売却率: 10%(したがって、残存率は90%)
現在の導入ベース: 100
年 | 2006 | 2007 | 2008 |
---|---|---|---|
販売予測 | 240 | 280 | 350 |
サービス可能製品(サービス調整ファクタ0.6を適用済み) | 144 | 168 | 210 |
サービス可能製品の合計(前期の導入ベース100を加算済み) | 244 (144+100) | 387 (168+219) | 558 (210+348) |
予測導入ベース(除・売却率10%を適用済み) | 219 | 348 | 502 |
故障率情報は、使用量、製品のライフサイクル・パターン、信頼性特性など、様々な要因に基づいて求めることができます。この項では、ユーザーから直接取得される使用量基準の故障率に焦点を絞ります。
導入ベース情報が不適切な場合は、製品とサービス部品の組合せの平均期間故障率を直接入力できます。例:
プリンタA - カートリッジx: 平均故障率は期間バケット当たり10.7%
プリンタB - カートリッジx: 平均故障率は期間バケット当たり1.73%
この例は、サービス部品が割り当てられている製品によってカートリッジxのようなサービス部品の故障率が異なる可能性があることを示しています。「サービス部品計画」→「設定」→「故障率」と移動することによってアクセスできる「故障率」ウィンドウを使用して、製品と部品の組合せの故障率を設定できます。
故障率は、時間単位当たりに故障する母集団の平均的な比率として表します。時間単位は製品母集団予測の期間バケット・サイズと同じにする必要があります。つまり、製品母集団予測が週バケット単位で行われている場合は、故障率も1週間当たりの比率で表します。平均故障率は時間に依存しません。つまり、指定された故障率が予測範囲全体にわたって適用されます。
導入ベース、故障率、返品率、除・売却率の設定を参照してください。
サービス部品への需要は、次の式に従って、導入ベースの母集団およびサービス部品固有の平均故障率によって変化します。
サービス部品の予測需要 (i,t) = SUM,j=1,n (予測製品母集団 (j,t) * 故障率 (i,j))
ただし、
iは製品jで使用されているサービス部品
nはサービス部品iを使用している製品の総数
前の例の続き:
カートリッジxはプリンタAとプリンタBの両方で使用されています。
プリンタA –カートリッジxの平均故障率: 0.107
プリンタB –カートリッジxの平均故障率: 0.0173
年 | 2006 | 2007 | 2008 |
---|---|---|---|
プリンタAの予測導入ベース | 219 | 348 | 502 |
カートリッジx – プリンタAの予測故障数 | 23 | 36 | 53 |
プリンタBの予測導入ベース | 527 | 658 | 807 |
カートリッジx – プリンタBの予測故障数 | 9 | 11 | 13 |
カートリッジxの予測需要合計 | 32 | 47 | 66 |
返品率と、サービス部品に対応する製品の母集団に基づいて、サービス部品の返品予測を計算できます。計算は製品母集団基準の予測と同様の方法で行われます。ただし、返品履歴が使用履歴の代わりに使用され、返品率が故障率の代わりに使用されます。
ユーザー指定の返品率
「故障率」ウィンドウに平均返品率を入力します。平均返品率と対応する製品の母集団が判明すれば、次の式を使用して返品を予測できます。
サービス部品の返品予測 (i,t) = Sj=1,n (予測製品母集団 (j,t) * 返品率 (i,j))
ただし、
iは製品jで使用されているサービス部品
nはサービス部品(i)を使用している製品の総数
導入ベース、故障率、返品率、除・売却率の設定を参照してください。
このプロファイル・オプションでは、予測を目的として同時に起動されるプロセスの数を決定します。複数のプロセスを構成することで予測の速度を上げることができます。
「サービス・サプライ・チェーン・プランナ」職責から「プロファイル」ウィンドウへ移動します。
「その他」→「プロファイル」>
「個別プロファイル値」ウィンドウが表示されます。
. 「プロファイル名」列で、「MSC: インライン予測のプロセス数」プロファイルを問い合せます。
プロセス数を入力します。
「保存」をクリックします
SPPでインライン予測を生成するだけでなく、Demantraでサービス部品の予測を生成し、その予測をSPPで使用することもできます。詳細は、Oracle Demantra Demand Managementユーザー・ガイドの「予測サービス部品」を参照してください。
Demantraのインプリメンテーション情報およびDemantraでのデータ収集の手順については、Oracle Demantraインプリメンテーション・ガイドの「Demantra Demand ManagementとEBSの統合」および「Demantra Demand ManagementとEBS Service Parts Planningの統合」を参照してください。
前述のように、Demantraはスペア部品の予測を生成でき、その予測をSPPで使用できます。Demantraは、サービス部品予測の生成中に、契約製品の導入ベースおよび個々の契約製品のサービス可能部品(フィールド交換可能ユニット)を考慮することができます。Demantraは、さらに、製品に含まれているこれらの部品の故障率を計算し、製品の予測導入ベースに基づいて部品の予測を生成できます。詳細は、Oracle Demantra Demand Managementユーザー・ガイドの「予測サービス部品」を参照してください。
Demantraのインプリメンテーション情報およびDemantraでのデータ収集の手順については、Oracle Demantraインプリメンテーション・ガイドの「Demantra Demand ManagementとEBSの統合」および「Demantra Demand ManagementとEBS Service Parts Planningの統合」を参照してください。
Copyright © 2010, Oracle and/or its affiliates.All rights reserved.