保守予測の管理方法

予測ロジックおよび検証

予測が生成されるたびに、影響を受ける資産が検証され、それらの資産が予測に適格であることが確認されます。

最初のチェックでは、アセットがコンテキスト・プログラムの保守組織または同じマスター組織内の組織のいずれかで動作することを確認します。資産が保守対応でない組織で動作している場合は、プライマリ組織関係も検索されます。
次に、アイテム・ベースの場合、影響を受けるアセット・リストに必ず含まれます。
その後、資産の定義に従って、資産が保守プログラムに対して有効化され、作業オーダーが作成されるようになります。
その後、オプトインが有効な場合、プレビューおよびプランニング予測のいずれかで、資産が予測に適格であることを確認します。
最後に、資産が適格な資産として検証されたため、該当する組織での予測間隔および期日の計算に進みます。

保守予測の生成時に、予測範囲(日数)に設定された値が考慮されます。この値は、保守組織工場パラメータ、プログラム・ヘッダーおよび作業要件で定義され、予測で期日がどのくらい先に生成されるかを制御します。日数の値は、プログラムの最下位レベルの定義に基づいて使用されます。予測の実行後、一部の期日が表示されない場合は、設定をレビューし、範囲ウィンドウ値を調整できます。詳細は、製造およびサプライ・チェーン資材管理の実装ガイドの「保守工場パラメータを設定するためのガイドライン」のトピックを参照してください。

デフォルトでは、保守可能組織で動作する資産は予測され、そのコンテキスト組織で作業オーダーが作成されます。これは、同じ保守組織に定義されているプログラムと、組織全体で資産に対して使用可能なプログラムの両方で発生します。相互保守組織に対して定義された関係は、プログラムでは考慮されず、サポートもされません。

保守対応でない組織で動作する資産の場合、それらはプログラムの組織で予測されるか、または資産を常に単一の保守組織で保守する必要がある場合は、非保守対応組織と保守組織の間のプライマリ関係としてサポートを定義できます。これにより、予測が生成され、この保守組織でのみ作業オーダーが作成されます。さらに、作業オーダーを予測および作成するすべての組織に対して、資産の基準品目が定義されていることを確認する必要があります。

最初の期日および資産の初期化

「保守予測の生成」プログラムで最初の期日をどのように計算するかを理解することが重要です。通常、要件は開始日から計算を開始し、現在の日付より後の将来の期日のみを返します。過去、現在または将来の日付を設定すると、異なる結果になります。いくつかの例については、「サイクル間隔」および「開始日の例」の項で説明し、より詳細な説明を次に示します。

過去の開始日を設定すると、その時点で計算が開始されます。期日が過去のインターバルの期限超過として計算された場合は、その期日をどう処理するかを決定する必要があります。結果は、勤務要件のタイプによって異なります。

カレンダまたは日間隔では、過去の間隔の期日がスキップされ、現在の日付より後の最初の期日のみが返されます。これらの要件の期日超過を設定すると、将来の最初の期日間隔にのみ影響します。
メーター・ベースの要件では、メーターの開始日、検針履歴および要件の開始日が考慮されます。過去の間隔の期限日はスキップされません。これは、このメンテナンスが必要であり、完了する必要があるとシステムで想定されるためです。したがって、現在の日付または将来の日付では、すべての期限超過インターバルが期日になることがあります。通常、これは望ましい結果ではありません。詳細は、後述の「アセット初期化」の項を参照してください。

開始日を現在または将来に設定した場合、その時点で計算が開始されます。現在の日付を設定すると、作成時刻が計算を妨げる可能性があるため、異なる結果になる可能性があります。現在の日付が7月31日であるカレンダおよび日方法の最初の期日の例を次に示します。

#	シナリオ	開始日	最初の期日	結果
1	毎週月曜日、カレンダーまたは7日おきにご利用いただけます。	31-Jul	8-Aug	現在の開始日を設定すると、おそらく翌日から計算が開始され、8月1日のようになります。したがって、最初の期日は8月です。
2	毎週月曜日、カレンダーまたは7日おきにご利用いただけます。	1-Aug	8-Aug	将来の開始日を設定することをお薦めします。予想どおり、期限は8月1日の開始日から7日ごとです。
3	毎週月曜日、カレンダーまたは7日おきにご利用いただけます。過去の開始日を設定します。	28-Jul	4-Aug	過去の開始日を設定すると、システムは7日ごとに28-Julに開始する予測を計算し、最初の期日間隔は現在の日付より後であるため8月4日になります。
4	毎週月曜日、カレンダーまたは7日おきにご利用いただけます。過去の開始日を設定し、さらに戻ります。	21-Jul	4-Aug	過去の開始日を設定すると、7日ごとに6月21日に開始する予測が計算されます。 7月28日の最初の期日が計算され、現在の日付より前であるためスキップされます。次の期日は、現在の日付より後の8月4日に計算されるため、最初の期日です。
5	毎週月曜日、カレンダーまたは7日おきにご利用いただけます。開始日を現在の日付より後の日付にさらに移動します。	15-Aug	22-Aug	開始日を現在の日付より前に設定すると、最初の期日も後でプッシュされます。 8月15日までは予測の計算は開始されません。予想どおり、期限は8月15日から7日ごとで、最初の期限は8月22日です。

現在の日付が31-Julであるメーターベースの方法を使用した最初の期日の例を次に示します。

#	シナリオ	開始日	最初の期日	結果
1	日次レート10に基づいて、70時間ごとに期限が切れるメーター。したがって、7日ごとに期限が切れます。資産メーターには検針履歴がありませんが、メーター開始日は8月1日です。	31-Jul	8-Aug	メーターの予測は、常にメーターの翌日の計算を開始するため、8月1日のメーター開始日を使用して、8月8日に70に達し、期限が切れていることが計算されます。
2	日次レート10に基づいて、70時間ごとに期限が切れるメーター。資産メーターには検針履歴がありませんが、メーター開始日は8月1日です。	1-Aug	8-Aug	シナリオ1と同じですが、1日後にメーターが8月1日に開始されてから、8月8日に70に達し、期限が切れていることが計算されます。
3	日次レート10に基づいて、70時間ごとに期限が切れるメーター。資産メーターには検針履歴がありませんが、メーター開始日は8月1日です。過去の開始日を設定します。	21-Jul	8-Aug	この場合、過去の開始日を設定すると、計算に影響します。メーターの開始日は8月1日で、検針履歴がないため、システムは2月21日から8月1日までのゼロの値を想定する必要があります。 8月1日から、メーターが耐用期間値70に達すると、最初の期日は8月8日の7日後になります。
4	日次レート10に基づいて、70時間ごとに期限が切れるメーター。資産メーターには、メーター開始日8月1日に検針120があります。過去の開始日を設定します。	21-Jul	31-Jul および 3-Aug	シナリオ3を取得し、開始日の8月1日に120の値で資産の検針を記録した場合。予測がどのように変化するかを見てみましょう。 8月1日に120の検針値が検索され、7月21日にメーター値が10になるという値が逆方向に計算されます。この日付から、1日当たり10日先送りが計算され、7月27日に70に達すると予想され、現在は期限超過とみなされます。これは、現在の日付31-Julの期日として表示されます。計算は継続され、7日後には7月27日から8月3日に140日に再度予定されます。したがって、2つの期日、現在の日付の期限超過間隔、将来の次の期日が表示されます。後で、資産の初期化によって期限超過日を防ぐ方法について説明します。
5	日次レート10に基づいて、70時間ごとに期限が切れるメーター。資産メーターには、メーター開始日8月1日に17,500の検針があります。過去の開始日を設定します。			シナリオ3を取得し、開始日の8月1日に17,500の値で資産のメーター読取りを記録した場合。この値がどのように検証されるかを見てみましょう。最初に、資産が最後に保守された時期がわからないため、シナリオ3のように履歴に戻り、70時間ごとに期日が計算されます。このメーターの例では、支払期限日の計算を防ぐために、次に詳しく説明するように資産を初期化する必要があります。
6	日次レート10に基づいて、70時間ごとに期限が切れるメーター。資産メーターには検針履歴がありませんが、メーター開始日は8月1日です。将来の開始日を設定します。	15-Aug	8-Aug および 15-Aug	この場合、将来の開始日を設定すると、計算に影響します。メーターの開始日は8月1日であるため、システムは8月15日に履歴の最新の検針を調べます。履歴がないため、アセットは8月1日から動作していると想定されるため、履歴を再作成する必要があります。 1日8回計算されるため、8月8日に64に達すると予想されていました。その後、8月15日の時点で、資産メーターは120と計算されます。これらのインターバルの両方の期日が期限超過として表示され、両方とも8月15日に期限が切れます。 8月15日から、メーターの値が176に達すると、次の期日が7日後22-Augと計算されます。後で、資産の初期化によって期限超過日を防ぐ方法について説明します。

資産初期化

前述のとおり、前回保守が実行されたことがシステムで認識されない場合は、要件「開始日」またはメーター開始日からのみ計算を開始できます。これにより、期限超過日を含む予期しない望ましくない予測結果が発生する可能性があります。

実装時には、ほとんどのアセットが存在するため、予防保守履歴があります。最初の期日を正しく計算するには、メンテナンスが実行された最終日と間隔を指定して、各資産の予測を初期化する必要があります。この同じプロセスは、新しい資産を導入する場合にも使用できます。「資産」タブでは、必要に応じて、「予測の初期化」ドロワーで次の値を設定できます。

履歴最終完了日: 作業定義が外部アプリケーションまたはレガシー・システムで最後に完了した日付を入力します。日付は現在の日付より前である必要があります。
履歴最終間隔: 作業要件が間隔でサイクルベースの場合、最終完了日に最後に保守を完了した間隔を入力します。

資産または資産ベースの要件の場合、履歴最終完了日を設定する場合は、要件開始日をこの日付と同じ日付、または将来の日付(現在の日付など)に設定する必要があります。要件開始日を履歴最終完了日より前に設定すると、履歴がさらに計算されますが、これはお薦めしません。結果は過去の期限超過日になりますが、ほとんどの場合は望ましくありません。

品目ベースまたは混合資産の要件では、要件開始日が各資産を初期化するのに十分でない場合があります。したがって、予測の初期化ドロワーで予測開始日を設定することをお薦めします。

需要予測開始日: この日付によって、要件開始日が上書きされます。
- 履歴最終完了日を設定する場合は、要件開始日をこの日付または将来の日付(現在の日付など)に設定する必要があります。
- 履歴最終完了日を設定しない場合は、現在の日付または将来の日付として日付を設定することをお薦めします。
- 要件開始日を履歴最終完了日より前に設定すると、履歴がさらに計算されますが、これはお薦めしません。結果は過去の期限超過日になりますが、これは望ましくありません。

資産の保守がメーター読取り履歴から除外される場合、最初の期日を正確に予測するには、メーター読取り履歴の記録が必要です。推奨事項は次のとおりです。

メーターの開始日 - 現在の検針またはゼロの検針を入力することをお薦めします。
- これにより、現在の使用率を計算するためのアンカー・ポイントが提供されます。
- 検針値がゼロでない場合は、保守のために次の期日を正確に計算する方法が認識されません。そのため、履歴最終完了日は、メーター読取りとともに最初の期日を計算するために役立ちます。
履歴最終完了日 - これは、メーターベースの要件を初期化するためのベスト・プラクティスです。
- この検針は、予測および初回期日を計算するための基準点として機能します。
- この日付に検針が入力されていない場合、履歴を振り返って最終検針が検索されます。これにより、目的の初回期日が生成されない場合があります。
- さらに、この日付および対応する検針は、1つのインターバルから過去までの期間より短くする必要があります。そうしないと、期限超過のインターバルの期日がスキップまたは作成されます。
その他の履歴検針 - メーター開始日後に入力された履歴検針は、履歴最終完了日に対応しないかぎり、最初の期日の計算に役立つ場合とそうでない場合があります。
- 履歴最終完了日より前の読取値は、履歴参照にのみ有用であり、予測計算では使用されません。
- 稼働率の変更が記録された実際の検針に反映されるため、過去の最終完了日以降の検針は、最初の期日を計算するのに役立ちます。ただし、最終完了日の間の見越検針が要件間隔を超えた場合、期限日はスキップされるか、期限超過として作成されます。

ノート:期限超過日の作成が必要な場合、または避けられない場合は、「予測の管理」ページを使用して、いつでも手動で日付を再スケジュールまたはスキップできます。

初期化の例は、現在の日付が6月31日であり、過去の最終完了日および予測開始日を設定すると、より正確な最初の期日になります。

#

シナリオ

開始日

履歴最終完了日

予測開始日

最初の期日

結果

1

資産または資産経路ベース。

毎週月曜日、カレンダーまたは7日おきにご利用いただけます。

要件「開始日」より前の履歴最終完了日を過去に設定します。

1-Aug

28-Jul

資産または資産経路の該当なし

4-Aug

「Historical Last Completed Date(履歴最終完了日)」を「Start Date(開始日)」の数日前に設定すると、「First Due Date(最初の期日)」が前の日付になります。

7日ごとに7月28日の開始日が計算され、8月1日の開始日より後の最初の期日間隔は8月4日になります。

2

資産または資産経路ベース。

毎週月曜日、カレンダーまたは7日おきにご利用いただけます。

「Start Date(開始日)」を先日付に移動します。

15-Aug

28-Jul

資産または資産経路の該当なし

18-Aug

開始日を「履歴最終完了日」より前に設定すると、最初の期日も後でプッシュされます。

7日ごとに、7月28日の開始日が計算されます。複数のインターバルが計算され、開始日より前になるためスキップされます。したがって、開始日が8月15日より後の最初の期日間隔は8月18日です。

次に、現在の日付が6月31日であるメーターベースの方法を使用した初期化の例を示します。過去の最終完了日と予測開始日を設定すると、より正確な最初の期日になります。

#	シナリオ	開始日	履歴最終完了日	予測開始日	最初の期日	結果
1	資産または資産経路ベース。日次レート10に基づいて、70時間ごとに期限が切れるメーター。資産メーターには、要件開始日より前の開始日が28-6月で、履歴最終完了日である8月8日のメーター読取りが120です。つまり、アセットは推定日次使用率で動作しています。	8-Aug	8-Aug	資産または資産経路の該当なし	15-Aug	8月8日の履歴完了日を使用して、120の検針が検索されます。予測は、8月の開始日に従ってこの時点から計算を開始し、1日当たり10ずつ増加します。次の期限は7日後の190年8月15日になる。最終完了日および対応する検針に入力したため、8月3日の値70で期限超過日は生成されませんでした。
2	シナリオ1の場合、資産が推定日次稼働率を下回る場合、8月8日の履歴最終完了日に90の検針がある可能性があります。	8-Aug	8-Aug	資産または資産経路の該当なし	15-Aug	メーターは7月28日に開始し、1日当たり10ずつ増分します。ただし、8月8日には、履歴完了日に90の検針しかないため、資産は予測日次レートで運用されています。予測は、8月の開始日に従ってこの時点から計算を開始し、1日当たり10ずつ増加し、160の値と8月15日の初回期日に達します。最終完了日および対応する検針に入力したため、8月3日の値70で期限超過日は生成されませんでした。
3	シナリオ1の場合、資産が推定日次稼働率上で実行されている場合、8月8日の履歴最終完了日に220のメーター読取りがある可能性があります。	8-Aug	8-Aug	資産または資産経路の該当なし	15-Aug	メーターは7月28日に開始し、1日当たり10ずつ増分します。ただし、8月8日には、履歴完了日に220の検針があるため、資産は日次レートで運用されます。予測は、8月の開始日に従ってこの時点から計算を開始し、1日当たり10ずつ増分し、値290、最初の期日は8月15日にヒットします。最終完了日および対応する検針に入力したため、8月3日の値70で期限超過日は生成されませんでした。
4	資産または資産経路ベース。日次レート10に基づいて、70時間ごとに期限が切れるメーター。資産メーターには、要件開始日より前の開始日が28-6月で、履歴最終完了日である8月8日のメーター読取りが120です。将来の予測開始日を設定します。	1-Sep	8-Aug	該当なし	期限超過: 8月15日-8月22日-8月29日-8月次は5日目。	シナリオ2を取得し、将来の開始日を1-Sepに設定すると、インターバルが計算され、複数の期限超過日が発生します。予測は、8月8日から8月15日に190、8月22日に260、8月29日に330、最後に5-Sepで400に達した値から計算を開始します。履歴開始日を将来の日付で調整して、最初の期日を制御できます。必要に応じて、「保守予測」ページを使用して、これらの期限超過日付を「スキップ」に設定することもできます。
5	品目ベースの要件を使用する場合、予測開始日が使用可能であり、要件の開始日を上書きするのに役立ちます。	8-Aug	8-Aug	1-Sep	15-Aug	シナリオ4を取得し、将来の開始日を1-Sepに設定すると、勤務要件の開始日ではなくこの値が使用されます。

保守予測に対する検針の影響

メーターベースの予測に対して最初の期日が設定されると、先日付の各インターバルおよび期日は、事前定義された日次または計算された稼働率に基づいて、期日と最初に計算されます。次に、定期的な検針が、資産の稼働状況履歴を記録し、その予測を動的に更新するために、期日間隔の間(理想的には期日間隔の間)に経時的に記録されることが期待されます。

インターバル間で検針が入力されていない場合、予測は動的に調整されず、期日はプッシュアウトされません。資産がアイドル状態の場合、将来の期日を調整するには、現在の検針であっても定期的に検針を入力する必要があります。そうしないと、将来の期日が調整されず、最終的に期限超過のメンテナンスが発生する可能性があります。

メーターが多数の検針に基づいて計算済稼働率を生成するように定義されている場合、最初に代表的な平均稼働率を生成する数値を定義することが重要です。次に、検針入力は稼働状況を最新の状態に保つために定期的に継続することが予想されます。そうしないと、メーターを使用して予測すると問題になるため、より低く移動し、最終的にゼロに到達します。

次の例を確認して、予測に対するメーター読取りの影響をさらに理解しましょう。

デリバリ・トラックは、1日当たり平均50マイルで稼働しています。それは定期的にサービスされ、5,000マイルごとにオイルを変えるので、通常100日ごとに期限があります。
最後にサービスを受けたのは、6月1日の30,000マイルでした。次の期日は、9日の35,000マイルで予測されます。
トラックの最後の検針は8月21日に34,500で入力されたので、35,000マイルから8月31日に到着する期日を調整した。
ワーク・オーダーは8月31日に作成され、監督者はその期日から数日後に2-Sepの翌週に再スケジュールします。
作業オーダーのレポート中に、技術者は、走行距離35,125マイルの現在の検針を入力します。

技術が最新の検針を記録する場合、通常、新しい検針が、検針間の期間中に予想される日次または計算済稼働率に従うことが期待されます。アイドル状態のアセットや、再割当されて通常より多く動作するアセットなど、読取り履歴の通常の変動が予測を動的に調整します。ただし、予測の再生成前に検出されない、予想より大幅に高い検針が記録された場合、予測に大きな影響がある可能性があります。

検針に入力した技術者の影響をレビューします。

検針が35,125マイルで正確に記録されている場合、予測は再計算され、期限は12月21日に40,125になります。
検針が35,125マイルで記録されていない場合、予測は履歴の最後の検針(8月21日に34,500)を使用して再計算され、725マイルおよび3週間前の39,500(11月29日)に期限が切れます。
検針が35,025で100マイルレポートされている場合、予測は再計算され、12月19日の40,025で期限が100マイルおよび2日前になります。
- 履歴の最終検針とレポート日時点の真の値の間で誤ってレポートされた検針では、期日が早いため早期サービスになります。
検針が35,215マイルで超過レポートされた場合、予測は再計算され、1月10日の40,215日、予想より2日遅れます。
- 実際の検針より誤って高いと報告されているが、予想される次の間隔である5,000マイルより前の検針は、次の期日をプッシュし、推奨サービス日を過ぎた資産の使用が延長されます。
メーター読取りが53,125マイルで大幅にレポートされる場合、影響は少し異なります。
- シナリオ1: 予測では推定日次稼働率が使用されます。
  - 次の期限は12月21日に58,215になる。
  - 32,125から58,215までのメンテナンスの反復はスキップされます。
  - 間隔のサイクルが使用されている場合、これらの間隔で期限が切れる作業定義はスキップされ、計画または完了されません。これにより、アセットのクリティカルなメンテナンスが完了しない可能性があります。
  - できるだけ早く正しい読取りを識別、編集または無効化して入力すると、問題の解決に役立ちます。
- シナリオ2: 予測では計算された日次稼働率が使用されます。
  - 計算された稼働率が劇的に上昇し、システムが期限超過していると考えているため、将来の期日が繰り越されます。
  - できるだけ早く正しい読取りを識別、編集または無効化して入力すると、問題の解決に役立ちます。
  - これらの日付の作業オーダーを作成する場合は、「保守予測」ページでそれらの作業オーダーを取り消して予測を再生成する必要がある場合があります。予定どおりに戻るには、ワーク・オーダーを手動で再スケジュールする必要がある場合もあります。

保守予測の生成

予測を定期的に作成および再生成して、プランナに最新データを提供します。次のいずれかのメソッドで、予測を作成して定期的に更新できます:

1つのプログラム内で、影響を受ける資産ページで、単一の作業要件の予測メソッドを検証するか、特定の含まれている資産のみを検証できます。これらの各メソッドは、プログラムの期日のサブセットについてのみ、予測を増分的に更新します。このメソッドは、プログラム内の新規または編集済作業要件の予測を作成または更新しつつ、プログラム全体の他の作業要件の予測期日の不要な再計算および再作成を排除するのに役立ちます。レスポンス時間の改善により、予測期日結果を迅速に評価できます。追加の考慮事項は次のとおりです。
- これらの処理は、「保守プログラム」パラメータで「全作業所要量の抑制およびマージの許可」資産保守パラメータを「いいえ」に設定した場合にのみ使用できます。それ以外の場合は、これらのアクションが無効になります。
- 既存のページでは、要件ステータスが「アクティブ」の場合にのみ予測を生成できます。したがって、結果の予測は稼働中であり、作業オーダーの表示および作成に適格です。
- Redwoodページでは、要件ステータスが「予測準備完了」になると予測を生成できます。これにより、モデリングを本番にリリースする前に検証して調整し、ステータスが「アクティブ」になります。
1つのプログラム内で、すべての作業要件および資産を生成またはリフレッシュできます。「処理」ドロップダウンから「予測の生成」ボタンを選択して、作業要件の予測メソッドを確認します。これにより、スケジュール済プロセスが実行され、予測ウィンドウのすべての作業要件および予測の資産にわたって予測が日数で作成および更新されます。大きなプログラムがある場合は、このプロセスを1日に2回以上実行しないでください。追加の考慮事項は次のとおりです。
- このオプションをページから無効にするには、資産保守パラメータを設定します。これにより、1日のアクティビティ時間が短い間のみ、プログラムをスケジュール済プロセスとして実行できます。その後、前述のオプションを使用して、必要に応じて要件レベルでのみ予測を生成できます。
プログラムの検証後、スケジュール済プロセスを使用して予測を定期的に実行するように設定します。ジョブには、Maintenance Managementランディング・ページのタスク・ペインから保守予測の生成リンクをクリックしてアクセスできます。このスケジュール済プロセスの詳細は、SCMのスケジュール済プロセス・ガイドを参照してください。

保守予測の生成スケジュール済プロセスが発行されると、プログラム・パラメータでカバーされる一意の保守プログラムがすべてロックされます。完了すると、プログラムがロック解除され、スケジュール済プロセスを再発行して予測を再生成できるようになります。スケジュール済プロセスがエラーで終了する場合や、ユーザーの介入によってプロセスが手動で停止される場合、プログラムがまだロックされている可能性があります。これにより、スケジュール済プロセスを使用して予測がさらに更新されなくなります。これが発生した場合は、このメソッドでプログラムのロックを解除できます。

同じ組織に1つの作業要件を持つ小規模なプログラムを作成します。
スケジュール済プロセスが組織またはプログラムに対して実行されていないことを確認してください。
小さいプログラムの場合、「予測の生成」をセッションで実行すると、組織内のすべてのプログラムがロック解除されます。
次に、問題が解決および確認されるまで、その時点で1つのプログラムに対して、スケジュール済プロセスを再度実行してみてください。また、質問や懸念がある場合は、Oracle Supportを使用して作業を調整する必要があります。

ノート: 個々のプログラムおよび各組織にわたるプログラムの予測を作成および更新するための調整作業を行うことをお薦めします。定期的にユーザー間で調整されていない個別の更新が実行された場合、売上予想の更新の一貫性を維持することが困難な場合があります。計画担当者が認識する定型間隔で予測を一貫して更新するには、スケジュール済プロセスを使用する必要があります。

最終完了に基づく先日付期日の調整

日間隔またはメーター間隔を予測メソッドとして使用する場合は、「次の作業オーダーのみ」チェック・ボックスを選択し、「次の期日の計算メソッド」を「最終完了」に設定することをお薦めします。これにより、前の作業オーダー完了および検針入力に基づいて、予測範囲内の将来の期日を動的に調整できます。それ以外の場合、保守プログラムの作業オーダーの最終完了を考慮して、予測が動的に予測されないことがあります。

ただし、作業オーダーが次の予測期日より前に完了しないビジネス・シナリオがある場合、予測は将来の期日を動的に調整およびプッシュ・アウトできません。予測順序がスキップされ、再予測および動的にプッシュ・アウトできないという問題が発生する場合があります。これらの日付を処理する唯一の方法は、「メンテナンス予測」ページを使用して作業オーダーを手動でスキップまたは作成することです。

この問題を解決するために、履歴の最後のオープン作業オーダーの予定完了日または実績完了日、および最新のメーター読取りに基づいて予測の将来の期日を調整できるようにする資産パラメータ・オプションを設定することをお薦めします。

パラメータには「最終完了オプションの使用時に将来の期日を調整するためのメンテナンス予測の許可」という資格があり、「設定およびメンテナンス」作業領域の「資産メンテナンス・パラメータの管理」で管理者が設定できます。

「いいえ(デフォルト)」に設定すると、予定完了日に基づいて履歴の最後の作業オーダーに基づいて次の期日が調整されず、予測の次の期日より後に完了した作業オーダーに対して調整されません。
「はい(推奨)」に設定すると、予測順序で最後にアクティブな作業オーダー(予定完了日または実績完了日)に基づいて次の期日が調整されます。このオプションを機能させるには、次の作業オーダー・オプション「はい」を使用するか、一度に1つのアクティブな作業オーダーのみを許可する予測ウィンドウが必要です。
- 作業オーダーの完了前に、作業オーダー予定完了日が更新された場合、予測の次のリフレッシュによって、次の予測順序の予測ウィンドウ内の次の期日が順番に、予測メソッドごとにプッシュまたはプルされます。
- 作業オーダーの完了後は、実績完了日に基づいて将来の予測が調整され、予測ウィンドウでの予測順序は維持されます。これには、予測での作業オーダーの期日の完了後に正しい順序を再作成するための予測順序の削除または再作成が含まれる場合があります。

メーター・リーディングを使用して予測をモデル化する場合、検針は体系的に、手動または作業オーダーの完了時に定期的に入力されることが予想されます。これらの検針は、次の期日シーケンスを予測するために使用されます。完了予定日を調整すると、その日付時点での予想検針が計算され、この値を使用して将来の期日が予測されます。

メンテナンス予測の生成処理時間

プロセスで大量の作業要件および影響を受ける資産が見つかった場合は、処理時間を短縮するために追加の子就業者をデプロイできるようになりました。デフォルトでは、1人の就業者がデプロイされますが、2000を超える作業要件と資産の組合せがプログラムで検出された場合、2人目の就業者は自動的にデプロイされます。

処理時間が長い場合、プログラム内の作業要件および資産が多数あるため、管理者がデプロイ可能な子ワーカーの数を増やすことで、処理時間が改善される場合があります。

管理者は、このプロファイル・オプションの「管理者プロファイル値の管理」タスクを使用して就業者数を設定できます:

プロファイル・オプション名: ORA_MNT_PROGRAM_NUM_WORKERS
プロファイル・オプション摘要: メンテナンス・プログラム・ジョブに対して生成されるエンタープライズ・スケジューラ・サービス・ワーカーの数。

従業員数を3から10まで増やすことをお勧めします。 3の値から開始し、その時点で1人のワーカーを増分して、処理時間の改善を検証する必要があります。

保守予測の検証

既存のページでは、予測の生成後、「ガント」タブまたは「カレンダ」タブを使用して、保守予測ページで資産または作業要件(あるいはその両方)を検索するか、OBTI分析またはレポートをレビューすることで、プログラム内の予測を表示および確認できます。売上予想のサイズと複雑さに応じて、適切なメソッドを選択します。

Redwoodページでは、要件ステータスが「予測準備完了」の間、「予測」タブで予測プレビューを検証することもできます。「有効」にプロモートすると、このタブでプランニング予測をレビューすることもできます。

プログラム内で、売上予想が正常に作成または更新されたことを確認できます。各プログラムの「概要」タブには2つのキー・インジケータがあり、最後に更新および予測された日時が示されます。

その後、プログラム内の「ガント・チャート」タブまたは「カレンダ」タブを使用して、または「保守予測」ページを検索して、各資産の予測モデリング結果を検証できます。ほとんどのモデリング・ソリューションでは、予測モデリングと一致する頻度と予定期日を簡単に確認できます。これには、予測のソース、間隔および含まれる作業定義など、期日に関する追加の詳細の表示が含まれます。

資産の新しい作業要件の作成時に、予測を生成してレビューし、小さな変更を加えてから予測を再生成して結果を検証する反復的なアプローチが必要になる場合があります。ただし、予測が確立され、作業オーダーが作成されたら、ソース作業要件の予測メソッドを変更する際に注意する必要があります。作業要件の更新に関する追加の詳細および考慮事項については、次の項で説明します。

また、保守プログラムおよび作業要件サブジェクト領域を使用して、プログラムの最新の更新を検証するためにOTBI分析またはレポートを使用できるようにすることをお薦めします。これらの更新は、予測明細サブジェクト領域の対応するOTBIレポートに対して検証できるため、最新のプログラム更新が予測に反映されているかどうかを確認できます。この比較により、予測の結果のケイデンスと期日を理解し、モデリング・メソッドに対する今後の更新をガイドできます。 OTBIの使用の詳細は、このユーザー・ガイドの「レポートおよびアナリティクス」の項で説明します。

予測明細サブジェクト領域に対する検証に使用できる保守プログラムおよび作業要件定義サブジェクト領域用のOTBIレポートのキー・フィールドは次のとおりです:

メンテナンス・プログラム - ヘッダー
- 作成日: プログラムが作成された日付が表示されます。作業要件詳細の作成および編集のベースライン日です。
- 最終更新日: ヘッダー属性が前回更新された日付を表示します。この日付には、作業要件の更新は反映されません。
- 最終予測日: これは、セッション内またはこのプログラムのスケジュール済プロセスを使用して、前回の予測が正常に完了した時期を把握するのに役立ちます。これは、「作業要件」および「予測」明細レベルでも追跡されます。
作業要件 - ヘッダー
- 作成日: 要件が作成された日付が表示されます。
- 最終更新日: ヘッダー属性が更新された最終時間を表示します。
  - 履歴予測頻度を最新のモデリング・メソッドと比較し、時間の経過とともに変更が行われたかどうかを把握できます。
- 最終予測日: 各要件の最終予測日が表示されます。プログラム最終予測日と比較して、プログラムの最終更新時に要件がアクティブ・ステータスであったかどうかを確認します。
  - 要件の作成日と最終更新日を最終予測日の日付と比較すると、要件の最新バージョンが予測で考慮されたかどうかが確認されます。
  - また、結果の予測明細ごとに、要件の最終予測日と最終予測日を比較して、明細とその期日の作成に最新バージョンまたは以前のバージョンが使用されたかどうかを確認できます。
- 開始日: 開始日は、最初の期日を決定するために重要です。ただし、最初の作業オーダーの作成後は、期日の順序が再設定されないため、開始日を更新しないでください。ただし、ユーザーが開始日を変更した場合は、最終予測日別の履歴予測と照合して確認できます。
作業要件 - 作業定義
- 作成日: 作業定義が要件に追加された日付が表示されます。
- 最終更新日: 定義が最後に更新された時間を表示します。
  - 作業定義最終更新日を要件の「最終更新日」および「予測最終日」と比較し、現在の作業定義詳細が予測で考慮されているかどうかを確認できます。
  - 作業定義を削除したり、作業定義を追加したり、その間隔値を編集したり、異なる予測更新間または異なる予測更新間でマージまたは抑制オプションとともに使用することはできますが、これにより、予測が混乱し、目的のモデリングおよびケイデンスを理解する際に問題が発生する可能性があります。
  - また、前回の作業定義または要件の更新以降に予測がリフレッシュされない場合、将来の予測はモデリングごとに同期されません。
- 間隔で繰返し: この値は、時間の経過とともに更新できます。これを使用して過去の予測履歴と比較し、加えられた変更を理解します。
作業要件 - 影響を受ける資産
- 作成日: この日付を使用して、要件に対してアセットが明示的に定義されている時期を確認します。
- 最終更新日: アセットが最後に更新された時間を表示します。要件の「最終更新日」および「予測最終日」と比較できます。
- 履歴詳細: 最初の作業オーダーが作成される前に更新されます。そのため、予測と比較して、モデリングの変更や影響を受ける資産の詳細を簡単に確認できます。

予測明細サブジェクト領域にOTBIレポートを使用して、保守プログラムおよび作業要件定義サブジェクト領域の最新の更新と比較します。このガイドの「レポートおよびアナリティクス」の項で説明するように、OTBI for Oracle Maintenanceのトピックでは、予測明細のOTBIアナリティクスの例など、すべてのサブジェクト領域に関するガイダンスを提供します。次に、分析例から確認するいくつかのキー・フィールドを示します:

プログラムの予測明細は、それぞれ作業要件、資産、予測順序、サイクル間隔で期日、予測期日でソートする必要があります。これにより、モデリング・メソッドと比較する予測履歴の論理的な順序が提供されます。
予測明細ID: 予測明細は、作業オーダーが作成されるまで、各予測更新によって削除および再作成され、新しい一意の明細IDになります。そのため、これらの値を一定期間比較して、明細が再作成された場合は、前の予測から後の予測に確認できます。
最終予測日: 作業オーダーがある明細の予測が更新された最終日が表示されます。作業オーダーが作成されると、予測ラインは確定されます。この日付を作業要件の対応する日付と比較し、最新の更新が予測明細に反映されているかどうかを確認できます。
予測連番および期日: 予測順序は、開始日時点の値1から始まり、予測範囲日数に対して前倒しで計算されます。開始日が過去の日付の場合、連番はその日付から計算されます。ただし、アプリケーション日付以降に期日が作成されます。そのため、1以外の値で予測から始まるインターバルのサイクルの予測順序を確認することが一般的です。
- 長期にわたる資産の所要量のケイデンスは、開始日、サイクルおよびインターバル(使用する場合)、作業定義期限(サイクル・ベースの場合)を予測明細と比較することによって分析されます。これにより、現在のモデリングが作業オーダーのないすべての先日付期日に対して正しく適用されているかどうかが検証されます。
- また、予測メソッドが最終完了オプションを使用している場合は、次の作業オーダーの完了後にのみ、予測次回期日が正確に再計算されます。
予測メーター・リーディング: 資産の稼働率メーターを使用して期日の計算を行う場合、この値は、先日付の各期日に資産の読取りが予測される場所を反映します。この値は、基準インターバル値とメーター稼働率を使用して計算されます。期日は、予測の更新時に実際のメーター・リーディング履歴に基づいて更新されます。

作業要件の更新

予測を検証するときに、1つ以上の資産について、期日が正しい順序に該当しないことを識別できます。新しく作成された作業要件の場合、予測を生成してレビューし、少し変更を加えてから予測を再生成して結果を検証する反復的なアプローチが必要になることがあります。これは、資産の初期定義時に、資産の予防保守について予測モデリングを検証する上で重要なステップです。

Redwoodページでは、要件が「予測準備完了」ステータスのときに予測プレビューを生成できます。これにより、「予測の管理」ページで期日を表示でき、作業オーダー作成に適格になる前に、モデリングおよび資産の初期化を検証できます。

ただし、既存の予測では、ソース作業要件の変更を検討する前に、「保守予測」ページで小さな変更を管理できます。作業オーダーの作成後にソース作業要件の予測メソッドを変更する場合は、常に注意が必要です。作業要件開始日を使用してケイデンスが確立されると、モデリング・メソッドによっては調整が難しい場合があります。

Redwoodページでは、ステータスを「アクティブ」から「予測準備完了」に戻すことにより、予測がプランニングで作成された後にのみ要件を編集できます。その後、「予測」タブで既存の予測を表示し、モデリングまたは資産の初期化を調整し、予測を再生成して変更を確認できます。

ノート: また、作業要件で資産の最初の作業オーダーを作成する前に、すべての予測モデリング・メソッドを確認することも重要です。それ以外の場合は、将来の期日に対して行うことができる調整に制限されます。

作業要件を編集する際には、既存の予測、将来の予測、および一般的にその履歴に対する影響を理解することが重要です。

予測は常に、スケジュールされたプロセスの日付から将来の日付に、予測範囲(日数)ごとに作成および再作成されます。ページで売上予想を生成する場合、現在の日付が使用されます。
作業オーダーのない既存の予測期日は削除され、再作成されます。過去の日付は保持され、更新されません。
予測期日が手動でスキップするように設定されている場合、またはリクエストされた期日または組織が定義されている場合、予測は期日を保持し、削除および再作成されません。さらに、この日付より前のすべての以前の期日も保持されます。つまり、予測はそれらを削除または再作成しません。これは、手動編集の履歴を保持し、必要に応じて予測期日を後で編集できるようにするために必要です。
予測期日が手動でリセットされ、スキップされないように、リクエストされた期日または組織が定義されている場合、予測期日は削除および再作成のために再検討されます。これには、手動編集のために保持されない個々の期日とその前のすべての期日が含まれます。
作業オーダーは、将来の期日および時間に対してのみ作成されます。したがって、そのスケジュール済プロセスがルーチン・ベースで実行するようにスケジュールされていない場合、過去の期日はスキップされ、作業オーダー作成の対象とされない可能性があります。「予測の管理」ページまたはREST APIを使用して、必要に応じてこれらの作業オーダーを手動で作成できます。
作業要件予測メソッドまたはパラメータを変更すると、将来の予測ペースが根本的に変わる可能性があります。過去にオリジナルまたは最後のモデリングを確認することは困難になります。そのため、ペースの大幅な変更が必要な場合に、新しい勤務要件を作成することをお薦めします。
日間隔またはメーター間隔を使用する場合は、基準間隔または最終完了のいずれかを使用して次の期日を計算するメソッドを選択する必要があります。予測に対して作業オーダーが作成されると、このメソッドを変更すると、将来の予測が大幅に変化する可能性があります。そのため、メソッドの更新時には注意が必要です。
Redwoodページで変更を確認したら、要件をできるだけ早くプランニングに昇格することが重要です。

「保守予測」ページを使用した予測の管理

「保守予測」ページまたはREST APIを使用して、予測を表示および更新することもできます。資産の期日の場合は、資産および予測メソッドに関するキー詳細を表示できます。さらに、次のことができます:

作業オーダーがまだ作成されていない場合は、リクエスト作業オーダー開始日を定義および更新します。これは、作業オーダー作成スケジュール済プロセスによって、作業オーダーが期日ではなくいつ作成されるかを手動で定義するのに役立ちます。リクエスト開始日は、予測内の最終期日と次の期日の間の値にのみ設定できます。
作業オーダーが作成されるリクエスト保守組織を定義および更新します。組織間で使用可能なプログラムによって期日が予測される場合は、予測された組織ではなく、別の保守可能な組織で作業オーダーを作成するようにリクエストできます。定義するには、このリクエストされた組織に同じ作業定義が必要です。
資産の期日をスキップします。期日の作業オーダーを作成しない場合は、スキップ済インジケータを「はい」に設定します。これにより、作業オーダー作成スケジュール済プロセスを使用した作業オーダー作成の期日は考慮されません。また、期日をスキップ解除することもできます。これにより、期日を現在または将来の日付にする場合に、スケジュール・プロセスの次回実行で期日を再検討できます。それ以外の場合は、作業オーダーを手動で作成できます。
期日の作業オーダーを手動で作成します。アクティブな作業オーダーがない期日の場合は、予測された期日および事業所に基づいて、またはリクエストされた開始日および事業所(定義されている場合)を使用して作業オーダーを作成できます。この処理は、期限の作業オーダーを作成するスケジュール済プロセス・リクエストを起動します。この処理は、ステータスが「計画済」、「未計画」、「スキップ済」または「取消済」の期日に役立ちます。
期日の作業オーダーを手動で取り消します。実行中にトランザクションが作成されていない場合は、作業オーダーを取り消すことができます。取消後も作業オーダー参照を表示できますが、ステータスは「取消済」に設定され、実行できなくなります。作業オーダーおよび期日は、将来の期日を生成するために予測スケジュール済プロセスによって考慮されます。また、期日にある取消済作業オーダーについては、同じロケーションまたはリクエストされたロケーションに新しい作業オーダーを手動で作成できます。

ノート: 次の作業オーダーのみを作成するように作業要件が定義されている場合、履歴の最後の作業オーダーのステータスが「完了」または「取消済」でないかぎり、将来の作業オーダーを手動で作成することはできません。

ノート: 予測の管理UIまたはREST APIで予測期日を手動で更新する場合は、注意が必要です。これらの更新により、予測スケジュール済プロセスの動作が根本的に変更されます。リクエストされた期日または組織で予測期日を更新した場合、または期日をスキップした場合、予測スケジュール済プロセスによって削除および再作成されません。さらに、この日付より前のすべての以前の期日も保持されます。つまり、予測は削除または再作成されません。したがって、作業オーダーの最終完了に依存して次の期日にドライブを再計算する予測メソッドがある場合、手動編集のために日付が保持されていると、更新された予測期日は表示されません。

キーワード・ベース検索

キーワード・ベースの検索を行うときに従うことができるヒントを次に示します:

検索では大文字と小文字が区別されません。作業オーダーまたは資産詳細で検索すると、資産計上済キーワードと資産計上なしキーワードの両方が一致します。
作業オーダーや資産番号などの全文検索を使用して検索できます。これにより、検索結果が絞り込まれます。
資産摘要の作業オーダーの最初の数桁やテキストなど、部分テキスト検索を使用することもできます。有効な検索には、「次で始まる」または「次を含む」を使用します。
ロット・ベースなど、ハイフン化されているテキストを使用して検索する場合、用語はOR条件を使用して検索されます。つまり、検索エンジンは、別々のテキスト値としてロットまたは基準を使用して検索します。
- ハイフン付きテキストでは、「ロット」や「基準」などの部分値テキストのみで検索することもできます。これにより、検索結果が広がります。
- 結果が見つからない場合、または結果が多すぎる場合は、「ロット・ベース」などのテキストの周りに引用符を追加して、正確なフレーズを検索してみてください。これは、同じ順序で正確な単語を含む結果のみを返すように検索に指示します。
アンダースコアがある単語(Lot_Basedなど)を使用して検索する場合、エンジンはこれを1つの単語とみなします。
- 部分的なキーワード検索には、アンダースコア付きの単語を使用しないでください。
- アスタリスクなどの特殊文字はサポートされていません。