How You Manage Maintenance Forecasts

Forecast Logic and Validations

Each time a forecast is generated, the system validates the affected assets and ensure that they are eligible to be forecasted.

The first check is to ensure that the asset operates either in the contextual program’s maintenance organization or in an organization that is in the same master organization. If the asset is operating in a non-maintenance-enabled organization, it will also look for a primary organization relationship or not.
Next, if it is item-based, it will ensure that it is included in the affected assets list.
Then, it will ensure that the asset is enabled for maintenance programs and to create work orders, per the asset’s definition.
After that, if the opt-in is enabled, it will confirm that the asset is eligible to be forecasted, either in the preview and planning forecast.
Finally, now that the asset is verified as an eligible asset, it will proceed with calculating its forecasted intervals and due dates in the applicable organization.

When generating the maintenance forecast, the application considers the value set for the Forecast Horizon in Days. This value is defined in the maintenance organization plant parameters, program header and work requirement, controlling how far into the future the forecast will generate due dates. The number of days value is used based on the lowest level of definition in a program. After a forecast is run, if some due dates aren't displayed, you can review the setup and adjust the horizon window values. For additional details, refer to the Guidelines to Set Up Maintenance Plant Parameters topic in the Implementing Manufacturing and Supply Chain Materials Management guide.

By default, an asset that operates in a maintenance-enable organization will be forecasted and have work orders created in its contextual organization. This occurs both in a program that is defined in the same maintenance organization, as well as programs that are enabled for assets across organizations. Relationships defined for reciprocal maintenance organizations are not considered, nor supported, in a program.

For assets that operate in non-maintenance-enabled organization, they will either be forecasted in the program’s organization, or if you wish for the asset to always be maintained in a single maintenance organization, then you can define a supports as primary relationship between the non-maintenance-enabled-organization and a maintenance organization. This will ensure the forecast is generated and work orders are created only in this maintenance organization. Additionally, you must ensure that the Asset’s base Item is defined for all organizations in which you will forecast and create work orders.

First Due Date and Asset Initialization

It is important to understand how the first due date will be calculated by the Generate Maintenance Forecast program. In general, a requirement will start calculating from its Start Date and only return future due dates after the current date. Setting a date in the past, present, or future will yield different results. Some examples are covered in the section Cycle Intervals and Start Date Examples, with a more detailed explanation below.

If you set a Start Date in the past, then the system will begin calculating at that point. If due dates are calculated as overdue for intervals in the past, the system will have to decide what to do with them. The results are different depending on the type of work requirement:

For a calendar or day interval, due dates on intervals in the past will be skipped, only returning the first due date after the current date. Setting a past due date for these requirements will only impact the first due interval in the future.
For a meter-based requirement, it will take the meter’s start date, reading history, and requirement Start Date into consideration. Due dates on intervals in the past will not be skipped, as the system must assume that this maintenance is required and must be accomplished. Therefore, on the current date or in the future, you may see all the overdue intervals as being due. This will generally not be a desirable outcome, please see the Asset Initialization section below for more details.

If you set a Start Date in the present or future, then the system will begin calculating at that point. Setting the present date may yield different results, as the time of day it is created can interfere with the calculation. Here are first due date examples for calendar and day methods where the present date is 31-Jul:

#	Scenario	Start Date	First Due Date	Outcome
1	Due every Monday using a calendar or every 7 days.	31-Jul	8-Aug	Setting a present Start Date will most likely result in the calculation starting the next day, as if it was the 1-Aug. Therefore, the first due date is 8-Aug.
2	Due every Monday using a calendar or every 7 days.	1-Aug	8-Aug	Setting a future Start Date is recommended. As expected, it is due every 7 days from the Start Date of 1-Aug.
3	Due every Monday using a calendar or every 7 days. Set a Start Date in the past.	28-Jul	4-Aug	Setting a past Start date results in the system will calculating the forecast beginning on the 28-Jul, due every 7 days, with the first due date interval is on 4-Aug, as it is after the present date.
4	Due every Monday using a calendar or every 7 days. Set a Start Date in the past, even further back.	21-Jul	4-Aug	Setting a past Start date results in the system will calculating the forecast beginning on the 21-Jul, due every 7 days. It will calculate the first due date on 28-Jul, which is skipped as it is before the present date. The next due date is calculated on 4-Aug, which is after the present date, thus is it is the first due date.
5	Due every Monday using a calendar or every 7 days. Move the Start Date further into the future after the present date.	15-Aug	22-Aug	Setting the Start Date further ahead of the present date pushes the First Due Date later as well. The system will not start calculating the forecast until the 15-Aug. As expected, it is due every 7 days from the Start Date of 15-Aug, first due on 22-Aug.

Here are first due date examples using the meter-based method where the present date is 31-Jul:

#	Scenario	Start Date	First Due Date	Outcome
1	Meter, due every 70 hours, based on a daily rate of 10. Therefore, it will be due every 7 days. The asset meter has no Meter Reading history, but a meter start date 1-Aug.	31-Jul	8-Aug	Forecasts for meters always start calculating the next day for a meter, so using the meter start date on 1-Aug, the system calculates that it reaches 70 on 8-Aug and is due.
2	Meter, due every 70 hours, based on a daily rate of 10. The asset meter has no Meter Reading history, but a meter start date 1-Aug.	1-Aug	8-Aug	Same as scenario 1, even though it starts 1 day later, since the meter started on 1-Aug, the system calculates that it reaches 70 on 8-Aug and is due.
3	Meter, due every 70 hours, based on a daily rate of 10. The asset meter has no Meter Reading history, but a meter start date 1-Aug. Set a Start Date in the past.	21-Jul	8-Aug	Setting a past Start date in this case impacts the calculation. Since the meter’s start date is 1-Aug, and there is no meter reading history, the system must assume a value of zero from 21-Jul to 1-Aug. Starting on 1-Aug the first due date is in 7 days later on 8-Aug when the meter reaches a life-to-date value of 70.
4	Meter, due every 70 hours, based on a daily rate of 10. The asset meter has a reading 120 on its meter start date 1-Aug. Set a Start Date in the past.	21-Jul	31-Jul and 3-Aug	If we take scenario 3 and record a meter reading for the asset on its start date of 1-Aug at a value of 120. Let’s see how the forecast changes. The system finds the reading of 120 on 1-Aug and calculates backwards that on 21-Jul it would have a meter value of 10. From this date, it calculates forward 10 per day and on 27-Jul it would have expected to have reach 70 and is now considered overdue. This will show as being due on the present date 31-Jul. The system will keep calculating, and 7 days later from 27-Jul it would be due again on 3-Aug at 140. Therefore, you will see 2 due dates, the overdue interval on the present date and the next due date in the future. We will discuss later how initializing the asset can prevent overdue dates.
5	Meter, due every 70 hours, based on a daily rate of 10. The asset meter has a reading 17,500 on its meter start date 1-Aug. Set a Start Date in the past.			If we take scenario 3 and record a meter reading for the asset on its start date of 1-Aug at a value of 17,500. Let’s see how the system validates this value. First, the system will not know when the asset was last maintained, so it will go back into history and calculate due dates for every 70 hours as in scenario 3. For this meter example, you must initialize the asset, as detailed below, to prevent overdue dates from being calculated.
6	Meter, due every 70 hours, based on a daily rate of 10. The asset meter has no Meter Reading history, but a meter start date 1-Aug. Set a Start Date in the future.	15-Aug	8-Aug and 15-Aug	Setting a Future Start date in this case does impact the calculation. Since the meter’s start date is 1-Aug, the system looks on the 15-Aug for the latest meter reading in history. Since there is no history, the system must recreate history, as the asset is assumed to have been operating since the 1-Aug. It calculates 8 per day, so on 8-Aug it would have expected to have reach 64 and be due. Then, as of the 15-Aug, the asset meter would be calculated to be at 120. The system will see both due dates on these intervals as being overdue, and they will both be due on 15-Aug. Starting from 15-Aug, the system calculates that the next due is 7 days later 22-Aug when the meter reaches a value of 176. We will discuss later how initializing the asset can prevent overdue dates.

Asset Initialization

As mentioned above, if the system does not know the last time maintenance was performed, it can only start calculating from the requirement Start Date, or meter start date, going forward. This can lead to unexpected and undesirable forecast results, including overdue dates.

During implementation, because most assets are existing, they will have preventative maintenance history. To correctly calculate the first due date, you will need to initialize the forecast for each asset by providing the last date and interval for which maintenance was performed. This same process can also be used in some cases for introducing new assets. In the Assets tab, for each asset you can optionally set these values in the Initialize Forecast drawer:

Historical Last Completed Date: Enter the last date the work definition(s) were accomplished in an external application or legacy system. The date must be before the current date.
Historical Last Interval: If the work requirement is cycle-based with intervals, then enter the interval at which you last completed maintenance on the Last Completed Date.

For an asset or asset-based requirement, if you are setting a historical last completed date, then you must set the requirement start date either equal to this date, or a date in the future, such as the current date. If you set a requirement start date before the historical last completed date, then the system will further calculate back in history, which is not recommended. The result will be overdue dates in the past, which is not desirable in most cases.

For an item-based or mixed asset requirement, the requirement start date may be not sufficient to initialize each asset. Therefore, it is recommended that you set the Forecast Start Date in the Initialize Forecast drawer:

Forecast Start Date: This date will override the requirement start date.
- If you are setting a historical last completed date, then you must set the requirement start date either equal to this date, or a date in the future, such as the current date.
- If you are not setting a historical last completed date, then setting a date as the current date or future date is recommended.
- If you set a requirement start date before the historical last completed date, then the system will further calculate back in history, which is not recommended. The result will be overdue dates in the past, which is not desirable.

If the asset’s maintenance is driven off meter reading history, then recording meter reading history is required to accurately forecast the first due. Here are the recommendations:

On the meter’s start date – it is good practice to enter its current meter reading or even a reading of zero.
- This provides an anchor point to calculate its current utilization.
- If the reading is not zero, then the system will not know how to accurately calculate the next due date for maintenance. This is why a historical last accomplished date is helpful, along with a meter reading, to calculate the first due.
On the historical last completion date – this is the best practice for initializing a meter-based requirement.
- This reading will serve as the anchor point to calculate its forecast and first due date.
- If a reading isn’t entered on this date, the system will look back into history and find the last reading. This may not produce the desired first due date.
- Additionally, this date and corresponding reading should be less than the duration of one interval into the past, else the system will skip or create due dates on intervals that are overdue.
Other historical readings – historical readings entered after the meter start date may or may not be helpful in calculating the first due date unless they correspond to the historical last completion date:
- Readings before a historical last completion date are only useful for historical reference and will not be used in the forecast calculation.
- Readings after the historical last completion date are helpful to calculation the first due, as changes in utilization will be reflected in the actual readings recorded. However, if the accrued readings between the last completion date exceed the requirement interval, due dates may be skipped or created as overdue.

Note: If the creation of overdue dates is required or even unavoidable, then you can always manually reschedule or skip the dates using the Manage Forecasts page.

Here are initialization examples are for calendar and day methods where the present date is 31-Jul, and setting a historical last completed date and forecast start date will result in a more accurate first due date:

#

Scenario

Start Date

Historical Last Completed Date

Forecast Start Date

First Due Date

Outcome

1

Asset or Asset-route based.

Due every Monday using a calendar or every 7 days.

Set a Historical Last Completed Date before the requirement Start Date, in the past.

1-Aug

28-Jul

N/A for asset or asset-route

4-Aug

Setting the Historical Last Completed Date a few days before the Start Date pulls the First Due Date earlier.

The system will calculate beginning on the 28-Jul, due every 7 days, with the first due date interval after the Start Date of 1-Aug is on 4-Aug.

2

Asset or Asset-route based.

Due every Monday using a calendar or every 7 days.

Move the Start Date further into the future.

15-Aug

28-Jul

N/A for asset or asset-route

18-Aug

Setting the Start Date further ahead of the Historical Last Completed Date pushes the First Due Date later as well.

The system will calculate beginning on the 28-Jul, due every 7 days. Several intervals will be calculated and skipped, as they fall before the Start Date. Therefore, the first due date interval after the Start Date of 15-Aug is on 18-Aug.

Here are initialization examples using the meter-based method where the present date is 31-Jul, and setting a historical last completed date and forecast start date will result in a more accurate first due date:

#	Scenario	Start Date	Historical Last Completed Date	Forecast Start Date	First Due Date	Outcome
1	Asset or Asset-route based. Meter, due every 70 hours, based on a daily rate of 10. The asset meter has a start date 28-Jul, before the requirement start date, and a meter reading of 120 on the historical last completed date of 8-Aug. This means the asset is operating on its estimated daily utilization.	8-Aug	8-Aug	N/A for asset or asset-route	15-Aug	Using the historical completed date of 8-Aug, the system finds a meter reading of 120. The forecast starts calculating from this point, in accordance with the 8-Aug Start Date, and increments 10 per day. The next due will be due 7 days later at 190 on 15-Aug. Because you entered in a last completed date and corresponding reading, the system didn’t generate overdue dates at a value of 70 on 3-Aug.
2	For scenario 1, if the asset is running below its estimated daily utilization, it may have a meter reading of 90 on the historical last completed date of 8-Aug.	8-Aug	8-Aug	N/A for asset or asset-route	15-Aug	The meter starts on 28-Jul and increments 10 per day. However, on the 8^th of Aug, on the historical completed date, there is a meter reading of only 90, so the asset operated under its expected daily rate. The forecast starts calculating from this point, in accordance with the 8-Aug Start Date, and increments 10 per day, hitting a value of 160 and a first due date on 15-Aug. Because you entered in a last completed date and corresponding reading, the system didn’t generate overdue dates at a value of 70 on 3-Aug.
3	For scenario 1, if the asset is running above its estimated daily utilization, it may have a meter reading of 220 on the historical last completed date of 8-Aug.	8-Aug	8-Aug	N/A for asset or asset-route	15-Aug	The meter starts on 28-Jul and increments 10 per day. However, on the 8^th of Aug, on the historical completed date, there is a meter reading of 220, so the asset operated over its daily rate. The forecast starts calculating from this point, in accordance with the 8-Aug Start Date, and increments 10 per day, hitting a value of 290 and a first due date on 15-Aug. Because you entered in a last completed date and corresponding reading, the system didn’t generate overdue dates at a value of 70 on 3-Aug.
4	Asset or Asset-route based. Meter, due every 70 hours, based on a daily rate of 10. The asset meter has a start date 28-Jul, before the requirement start date, and a meter reading of 120 on the historical last completed date of 8-Aug. Set a future Forecast Start Date.	1-Sep	8-Aug	N/A	Overdue: 8-Aug 15-Aug 22-Aug and 29-Aug. Next due 5-Sep.	If we take scenario 2 and set a future Start Date of 1-Sep, the system will calculate the intervals, resulting in several overdue dates. The forecast starts calculating from 8-Aug hitting a value of 190 on 15-Aug, 260 on 22-Aug, 330 on 29-Aug and finally 400 on 5-Sep. You can adjust the historical start date later in the future to control the first due date. You can also optionally set these overdue dates to Skipped using the Maintenance Forecasts page.
5	When using an item-based requirement, the Forecast Start Date is available and helpful to override the requirement’s Start Date.	8-Aug	8-Aug	1-Sep	15-Aug	If we take scenario 4 and set a future Start Date of 1-Sep, the system will use this value instead of the work requirement start date.

Meter Reading Impacts on Maintenance Forecasts

Once the first due date is established for a meter-based forecast, each future interval and due date will be initially calculated as being due based on its pre-defined daily or calculated utilization rate. Then, it is expected that periodic meter readings will be recorded over time, ideally between due date intervals, to both record an asset’s utilization history and dynamically update its forecast.

If readings are not entered between intervals, then the forecast will not dynamically adjust, and due dates will not push out. If an asset is idle, you must periodically enter in a reading, even if it’s the current reading, to adjust the future due dates. Else, the future due dates will not adjust, and you may eventually encounter overdue maintenance.

If your meters are defined as generating a calculated utilization rate based on a number of readings, it is important that you first define a number that when will produce a representative average utilization rate. Then, it is expected that meter reading entry will continue periodically to keep the utilization up to date, else it will move lower and eventually reach zero, which will be an issue if you forecast using the meter.

Let’s review this example to further understand the impact of meter readings on a forecast:

A delivery truck operates on average 50 miles per day. It is regularly serviced, changing its oil every 5,000 miles, so it is usually due about every 100 days.
The last time it was serviced was at 30,000 miles on 1-June. The system forecasts its next due date at 35,000 miles on 9-Sep.
The truck’s last meter reading was entered at 34,500 on 21-Aug, so it adjusted the due date when it will reach 35,000 miles to 31-Aug.
A work order is created on 31-Aug and a supervisor reschedules it for the following week on the 2-Sep, a few days after its due date.
During work order reporting, Technician will enter a current meter reading for its odometer of 35,125 miles.

When the Technical records the latest meter readings, it is generally expected that new readings will follow the expected pre-defined daily or calculated utilization rate over the period between readings. Normal fluctuations in reading history are expected, such as an asset that is idle, or an asset that is reassigned and operates more than usual will dynamically adjust the forecast. However, if a meter reading is recorded that dramatically higher than expected, and not discovered before the forecast is regenerated, there may be significant impact on the forecast.

Let’s review the impact of the Technician entering in the meter readings:

If a meter reading is accurately recorded at 35,125 miles, then the forecast will recalculate and be due at 40,125 on 21-Dec.
If a meter reading is not recorded at 35,125 miles, then the forecast will recalculate using the last reading in history, 34,500 on 21-Aug, and will de due 725 miles and three weeks earlier at 39,500 on 29-Nov.
If a meter reading is under reported by 100 miles at 35,025, then the forecast will recalculate and be due 100 miles and 2 days earlier at 40,025 on 19-Dec.
- A reading that is incorrectly reported between the last reading in history and the true value as of the reporting date will draw the due date earlier, leading to early servicing.
If a meter reading is over reported at 35,215 miles, then the forecast will recalculate and be due at 40,215 on 10-Jan, 2 days later than expected.
- A reading that is reported incorrectly higher than the actual reading, but before the expected next interval of 5,000 miles, will push the next due date out, causing extended use of the asset past its recommended service date.
If a meter reading is vastly over reported at 53,125 miles, then the impact is a little different:
- Scenario 1: Forecast uses an estimated daily utilization rate:
  - The next due will be at 58,215 on 21-Dec.
  - The system will skip each of the iterations of maintenance between 32,125 and 58,215.
  - If a cycle of intervals is used, then the work definition(s) due at these intervals are skipped and will not be planned or accomplished. This could lead to not accomplishing critical maintenance for your assets.
  - Quickly identifying, editing, or disabling and entering the correct reading as soon as possible will help to resolve the issue.
- Scenario 2: Forecast uses a calculated daily utilization rate:
  - The calculated utilization rate will dramatically rise, bringing forward future due dates as the system thinks they are now overdue.
  - Quickly identifying, editing, or disabling and entering the correct reading as soon as possible will help to resolve the issue.
  - If work orders are created for these dates, you may need to cancel them in the Maintenance Forecasts page and regenerate the forecast. You may also need to manually reschedule work orders to get back on track.

Generate Maintenance Forecasts

Create and regenerate forecasts regularly to provide latest data to your planners. You can create and periodically update the forecast by one of these methods:

Within a single program, you can verify the forecast methods for a single work requirement or only a specific included asset in the affected assets page. Each of these methods incrementally update the forecast only for a subset of due dates for the program. This method is useful to create or update the forecast for a new or edited work requirement within a program, while eliminating the unnecessary recalculation and recreation of forecast due dates for other work requirements across the program. The improved response time lets you to evaluate the forecast due date results quickly. Some additional considerations are:
- These actions are only available if you set the asset maintenance parameter Allow Suppress and Merge Across Work Requirements in a Maintenance Program parameter to No. Else, these actions will be disabled.
- In the existing page, you can only generate the forecast once the requirement status is Active. Therefore, the resulting forecast is live and is eligible to be viewed and create work orders.
- In the Redwood page, you can generate the forecast once the requirement status is Ready to Forecast. This gives you the ability to validate and refine your modeling, prior to releasing it to production and a status of Active.
Within a single program, you can generate or refresh all the work requirements and assets. Verify the forecast methods for the work requirements by selecting from the Actions drop-down the Generate Forecast button. This runs a scheduled process to create and update the forecast across all work requirements and assets in the program for forecast window in days. If you have large programs, don't run this process more than once in a day. Some additional considerations are:
- You can disable this option from the pages by setting an asset maintenance parameter, allowing you to only run the program as a scheduled process during a low activity time in a day. You can then use the options above to generate the forecast only at the requirement level, if enabled.
After a program is validated, set up the forecast to periodically run using a scheduled process. The job can be accessed from the Tasks pane on the Maintenance Management landing page by clicking the Generate Maintenance Forecast link. For additional details about this scheduled process, refer to the Scheduled Processes for SCM guide.

When the Generate Maintenance Forecast scheduled process is submitted, it locks all the unique Maintenance Programs covered by the program parameters. When it completes, it unlocks the program so that its forecast can be generated again by resubmitting the scheduled process. In the rare case where a scheduled process ends in error or when a process is manually stopped by user intervention, there's a chance the program is still locked. This prevents further updates of its forecast using the scheduled process. If this occurs, you can unlock the program by this method.

Create a small program with 1 work requirement in the same organization.
Ensure the scheduled process is not running for the organization or program.
For the small program, run the Generate Forecast in-session, this should unlock all the programs in the organization.
Then try running the Scheduled Process again, perhaps for one program at the time until the issue is resolved and confirmed. You should also coordinate efforts with Oracle Support if you have any questions or concerns.

Note: It is recommended to have a coordinated effort for creating and updating the forecast of individual programs as well as programs across each organization. If individual updates are performed that are not coordinated across users on a regular basis, it can be difficult to maintain consistency in updating the forecasts. Scheduled processes should be used to consistently update the forecast on a routine interval that is known by your planners.

Adjust Future Due Dates Based on Last Completion

We recommend that if Day or Meter Intervals are used as the forecast method, you select the Next work order only check box and set the Method to Calculate Next Due as Last Completion. This allows a dynamic adjustment of future due dates within the forecast horizon based on previous work order completion and meter reading entry. Else, the forecast may not dynamically forecast taking into consideration the last completion of a work order for a maintenance program.

However, if you have business scenarios where work orders are not completed before the next forecasted due date, the forecast is unable to dynamically adjust and push out future due dates. You may encounter issues with forecast sequences getting skipped over and not available to be re-forecasted and pushed out dynamically. The only way to handle these dates is to manually skip or create work orders using the Maintenance Forecast page.

To solve this issue, we recommended setting an asset parameter option that will enable the capability to adjust future due dates in the forecast based on either the scheduled or actual completion date of the last open work order in history, along with the latest meter reading.

The parameter is entitled Allow Maintenance Forecast to Adjust Future Due Dates When Using the Last Completion Option and can be set by an administrator in the Manage Asset Maintenance Parameters in the Setup and Maintenance work area.

When set to No (default), the system will not adjust the next due dates based on the last work order in history based on the scheduled completion date and it will not adjust for work orders completed after the next due date in the forecast.
When set to Yes (recommended), the system will adjust the next due dates based on the last active work order, either scheduled or actual completion date, in the forecast sequence. For this option to work, you should either use the next work order option = Yes or have a forecast window that will allow only one active work order at the time.
- Prior to work order completion, if the work order scheduled completion date is updated, then the next refresh of the forecast will push or pull the next due dates within the forecast window of the next forecast sequences in order and per the forecast method.
- After work order completion, the system will adjust the future forecast, based on the actual completion date, while maintaining the forecast sequence over the forecast window. This may include deleting or recreating forecast sequences to recreate the correct sequence after the completion of the work order’s due date in the forecast.

If you are modeling a forecast using meter readings, it is expected that readings are routinely entered systematically, manually or during work order completion. The system uses these readings to forecast the next due date sequences. If you adjust a scheduled completion date, the system will calculate what the expected reading is as of that date, and use this value to project the future due dates.

Generate Maintenance Forecasts Processing Time

If the process finds large numbers of work requirements and affected assets, the system can now deploy additional child workers to improve processing time. By default, the system will deploy a single worker, but if more than 2000 work requirement and asset combinations are detected in a program a second worker will be automatically deployed.

If you are still experiencing long processing times, due to a large number of work requirements and of assets within a program, you may see improve processing time by having an Administrator increase the number of child workers that can be deployed.

An administrator can set the number of workers using the Manage Administrator Profile Values task for this profile option:

Profile Option Name: ORA_MNT_PROGRAM_NUM_WORKERS
Profile Option Description: Number of Enterprise Scheduler Service Workers to be spawned for the Maintenance Program Jobs.

We recommend increasing the number of workers between 3 and a maximum value of 10. You should start at a value of 3, then increment one worker at the time, verifying improvement or not in the processing time.

Validate a Maintenance Forecast

In the existing page, after a forecast is generated, you can view and confirm a forecast within the program using the Gantt or Calendar tabs, by searching for an asset and/or the work requirement on the Maintenance Forecasts page or reviewing an OBTI analysis or report. Depending on the size and complexity of a forecast, you will pick the appropriate method.

In the Redwood page, you can also validate the forecast preview in the Forecasts Tab while the requirement status is Ready to Forecast. Once promoted to Active, the planning forecast can also be reviewed in this tab.

Within the program, you can confirm that a forecast has been successfully created or updated. There are 2 key indicators located on the Overview tab of each program and tell you when it was last updated and forecasted.

You can then validate the forecast modeling outcome of each asset using the Gannt Chart or Calendar tabs within the program, or by searching the Maintenance Forecasts page. For most modeling solutions, you can easily verify the cadence and expected due dates match your forecast modeling. This includes viewing additional details about a due date, such as the source of the forecast, interval, and work definitions that are included.

During the creation of new work requirement for an asset, you may need an iterative approach where you generate and review the forecast, make small modifications, then regenerate the forecast to verify the outcome. However, once a forecast has been established and work orders have been created, care should be taken when modifying the forecast methods of the source work requirement. Additional details and consideration around updating a work requirement is covered in the next section.

It is also recommended to have an OTBI analysis or report available to verify the latest updates to a program using the Maintenance Program and Work Requirement subject areas. These updates can then be validated against the corresponding OTBI report for the Forecast Line subject area, allowing you to confirm if the latest programs updates are reflected in the forecast or not. This comparison provides you the ability to understand the resulting cadence and due dates in the forecast and help guide any future updates to the modeling methods. Additional details on using OTBI are covered in this user guide in the section entitled Reports and Analytics.

Here are the key fields in an OTBI report for the Maintenance Program and Work Requirement definition subject areas that can be used to validate against the Forecast Lines subject area:

Maintenance Program - Header
- Creation Date: Shows the date when a program was created. This is the baseline date for the creation and editing of work requirement details.
- Last Updated Date: Shows the date when the header attributes were updated last time. This date doesn't reflect work requirement updates.
- Last Forecasted On Date: This is helps you know when the last forecast successfully completed, either in-session or using the scheduled process for this program. This is also tracked at the Work Requirement and Forecast line level.
Work Requirement - Header
- Creation Date: Shows the date when the requirement was created.
- Last Updated Date: Shows the last time when header attributes were updated.
  - You can compare the historical forecast cadence against the latest modeling method to understand if any changes were made over time.
- Last Forecast Date: Shows the last forecast date for each requirement. Compare it with the Program Last Forecast Date to know if the requirement was in an active status when the last time a program was updated.
  - Comparing the Creation and Last Updated dates on the requirement with that of the Last Forecast Date confirms if the latest version of the requirement was considered in the forecast.
  - Also, you can compare the requirement’s Last Forecasted Date with the Last Forecasted Date in each resulting Forecast Line to know if the latest or an earlier version was used to create the line and its due date.
- Start Date: The start date is important to determine the first due date. However, after the first work order is created, the start date shouldn’t be updated, because it won't re-sequence the due dates. However, if any user changed the start date, you can verify it against the historical forecast by Last Forecast Dates.
Work Requirement - Work Definitions
- Creation Date: Shows the date when work definition was added to the requirement.
- Last Updated Date: Shows the last time the definition was updated.
  - You can compare a Work Definitions Last Updated Date with the requirement’s Last Updated Date and Forecast Last Date to verify if the current Work Definition details are considered in the forecast.
  - Though you can delete a work definition, add a work definition, or edit its interval value, along with merge or suppress option between or across different forecast updates, this can cause a confusion in forecast and issues in understanding the intended modeling and cadence.
  - Also, if a forecast isn't refreshed since the last work definition or requirement update, the future forecast won't be in sync per the modeling.
- Repeats At Interval: This value can be updated over time. Use this to compare with the past forecast history to understand the changes made.
Work Requirement - Affected Assets
- Creation Date: Use this date to verify when the asset explicitly defined for the requirement.
- Last Updated Date: Shows the last time an asset was updated. You can compare it with the requirement’s Last Updated Date and Forecast Last Date.
- Historical Details: Are updated before the first work order is created. So, it's easy to compare with the forecast to verify any changes in the modeling and the affected asset details.

Use an OTBI report for the Forecast Lines subject area to compare against the latest updates to the Maintenance Program and Work Requirement definition subject areas. As covered in the Reports and Analytics section of this guide, the topic OTBI for Oracle Maintenance provides guidance on all the subject areas, including an example of an OTBI analysis for the Forecast Lines. Here are some key fields from the analysis example to review:

Forecast Lines for a program should be sorted by Work Requirement, Asset, Forecast Sequence, Due at Cycle Interval, and Forecast Due Date respectively. This provides a logical order of forecast history to compare against the modeling methods.
Forecast Line ID: A Forecast Line is deleted and recreated by each forecast update until a work order is created, resulting in a new unique Line ID. Therefore, you can compare these values over a time to confirm from a previous forecast to a later forecast if the lines were recreated.
Last Forecast Date: You see the last date when a forecast was updated for a line with a work order. After a work order is created, the forecast line is frozen. This date can be compared against the corresponding dates in the work requirement to verify if the latest updates are reflected in the forecast lines.
Forecast Sequence and Due Date: The Forecast Sequence starts as of the Start Date at a value of 1 and is calculated forward for the forecast horizon number of days. If the Start date is in the past, the sequence is calculated from that date, but it only produces due dates from the application date forward. Therefore, it may be common to see a forecast sequence for a cycle of intervals starting in the forecast at a value other than 1.
- The cadence of a requirement for an asset over time is analyzed by comparing the Start Date, Cycle, and Intervals (if used), Work Definition Due Intervals (if cycle-based) against the Forecast Lines. This verifies if the current modeling is correctly applied for all future due dates without a work order.
- Additionally, if the forecast method is using a last completion option, then forecasted next due is recalculated accurately only after the next work order is completed.
Forecast Meter Reading: If utilization meters for an asset are used to calculate the due dates, this value reflects where the forecast anticipates the reading of the asset each future due date. This value is calculated using the base interval value and meter utilization rates. The due dates are then updated based on the actual meter reading history when a forecast is updated.

Update a Work Requirement

As you are validating a forecast, you may identify due dates are not falling on the correct sequence for one or more assets. For a newly created work requirement, you may need an iterative approach where you generate and review the forecast, make small modifications, then regenerate the forecast to verify the outcome. This is an important step in validating the forecast modeling for an asset’s preventative maintenance during its initial definition.

In the Redwood page, you can generate a forecast preview while the requirement is in Ready to Forecast status. This will provide you the ability to verify your modeling and asset initialization before the due dates are viewable in the Manage Forecasts page and eligible for work order creation.

However, for an existing forecast, you may wish to manage small changes in the Maintenance Forecasts page before considering any changes to its source work requirement. Care should always be taken when modifying the forecast methods of the source work requirement once work orders are created. Once a cadence is established using the work requirement start date, it may be difficult to adjust it depending on the modeling methods.

In the Redwood page, you can only edit a requirement after the forecast has been created in planning by reverting the status from Active to Ready to Forecast. You can then view the existing forecast on the Forecast tab, adjust your modeling or asset initialization, and regenerate the forecast to verify the changes.

Note: It is also essential that you verify all your forecast modeling methods prior to creating the first work order for an asset in a work requirement. Else, you will be limited to the adjustments you can make to future due dates.

When editing a work requirement, it's important to understand the impact to the existing forecast, future forecast, and in general its history.

Forecasts are always created and recreated from the date of the scheduled process into the future, per the forecast horizon in days. If you generate a forecast in the page, it will use the present date.
Existing forecast due dates, without work orders, are deleted and recreated. Past dates will be preserved and not updated.
If a forecast due date has been manually set to be skipped, or a requested due date or organization is defined, then the forecast preserves the due date and it won't be deleted and recreated. Additionally, all previous due dates before this date are also preserved, which means the forecast won't delete or recreate them. This is necessary to maintain history of the manual edits and allow the forecasted due dates to be later edited as required.
If a forecast due date is manually reset to not be skipped, have a requested due date or organization defined, then the forecast due dates will be reconsidered for deletion and recreation. This includes the individual due dates and all due dates before it in history that are not preserved due to manual edits.
Work Orders are created only for due dates and times in the future. Therefore, it's possible that due dates in the past are skipped and not considered for work order creation if that scheduled process isn't scheduled to run on a routine basis. You can use the Manage Forecasts page or REST API to manually create these work orders, as required.
Changes to the work requirement forecast method or parameters may fundamentally change the future forecast cadence. It becomes difficult to verify the original or last modeling in the past. Therefore, it may be advisable to create new work requirements when a significant change in cadence is required.
If you use a Day or Meter interval, you must choose a method to calculate the next due dates as either using the base interval or the last completion. Once work orders are created for a forecast, changing this method could result in dramatic changes to a future forecast. Therefore, care should be taken when updating the method.
Once you have verified the changes in the Redwood page, it is important to promote the requirement to planning asap.

Manage the Forecast Using the Maintenance Forecast Page

You can also view and update the forecast using the Maintenance Forecasts page or REST API. For an asset’s due date, you can view key details about the asset and forecast method. Additionally, you can:

Define and update a requested work order start date if a work order has not been created yet. This is helpful to manually define when a work order will be created, instead of its due date, by the work order creation scheduled process. The requested start date can only be set to a value between the last and next due date in the forecast.
Define and update a requested maintenance organization where the work order will be created. If the due date is forecasted by a program that is enabled for cross-organizations, then you can request the work order to be created in another maintenance-enabled organization, instead of its forecasted organization. This requested organization must have the same work definitions in order to be defined.
Skip a due date for an asset. In case you don't want to create a work order for a due date, set the skipped indicator to Yes. This won't consider the due date for work order creation using the work order creation scheduled process. You can also un-skip a due date, which allows the due date to be reconsidered by the next run of the schedule process if the due date is in the present or future. Else, you can manually create a work order.
Manually create a work order for a due date. For a due date without an active work order, you can create a work order based off the forecasted due date and location, or by using the requested start date and location, if defined. This action will launch a scheduled process request to create the work order for the due date. This action is useful for due dates with a status of Planned, Unplanned, Skipped or Canceled.
Manually cancel a work order for a due date. You can cancel the work order if no transactions have been created in execution. Even after canceling, you can still view the work order reference, but it will be set to a status of Canceled and will not be available for execution. The work order and due date will be considered by the forecast scheduled process to generate future due dates. Additionally, for a Canceled work order on a due date, you can manually create a new work order in the same or requested location.

Note: If a work requirement is defined to create only the next work order, you can’t manually create any future work orders unless the last work order in history is in a status of completed or canceled.

Note: Care should be taken when you manually update a forecasted due date in the Manage Forecast UI or using the REST API. These updates fundamentally change the behavior of the forecast scheduled process. If you update a forecast due date with a requested due date or organization, or skip the due date, it won't be deleted and recreated by the forecast scheduled process. Additionally, all previous due dates before this date will also be preserved, which means the forecast won't delete or recreate them. Therefore, if you have a forecast method that relies on the last completion of a work order to recalculate the drive the next due date, you won't see an updated forecast due date if the date is preserved due to manual editing.

Keyword-Based Searches

Here are some tips you can follow when you do keyword-based searches:

Searches are case insensitive. Both capitalized and non-capitalized keyword terms match when searching by work order or asset details.
You can search using a full-text search, such as a work order or asset number. This narrows your search results.
You can also use a partial-text search, such as the first few numbers of a work order or text in an asset description. Use starts with or contains for an effective search.
If you search using text that is hyphenated, such as Lot-Based, the terms are searched using an OR condition. That is, the search engine searches using Lot or Based as separate text values.
- With hyphenated text, you can also search by only a partial value text, such as Lot or Based. This broadens your search results.
- If you don’t find your results or you get too many results, try searching for an exact phrase by adding quotation marks around the text such as, "Lot-Based" . This tells the search to only return results that contain the exact words in the same order.
If you search using a word that has an underscore, such as Lot_Based, the engine considers this as a one word.
- Don't use word with underscore for a partial keyword search.
- Special characters, such as asterisks aren't supported.