Overview of Maintenance Programs

Maintenance programs are used to define and generate a daily preventative maintenance forecast for one or more affected assets operating in a maintenance-enabled or non-maintenance-enabled organization. The forecast is used as the basis for creating preventative maintenance work orders, thus reducing the workload for maintenance planners, and allowing them to focus on maintenance program auditing, optimization, and exception-based events.

Programs can also be used to model preventative maintenance using asset routes. Asset routes allow you to centrally plan, execute, and record maintenance for a collection of assets using a single work order based on a unique route asset.

The programs are generally based on an OEM (original equipment manufacturer) service manual. This service guidance is translated and adjusted to fit a customer's operational requirements through the creation of work definitions. Then, these definitions are used as the basis for the creation of work requirements, which defines how often they're due. The forecast can be created based on a calendar pattern, day interval, utilization meter.

Go through the How You Manage Maintenance Programs section to get a comparison of functionalities between the existing page and the Redwood enabled page featuring Smart Search. To enable the Redwood page, you need to enable an opt-in and indexes. See the Maintenance chapter of the Implementing Manufacturing and Supply Chain Management guide for more information.

Key Considerations

Along with the program modelling and its work requirements using the available methods, it's important to know the impact of configuring the forecast options:

Option	Recommendations
Enabling programs for assets across organizations	Programs are always created in the context of a specific maintenance-enabled organization. But, before you create any programs, consider if the program manages only the assets operating in the same organization or it also considers assets that are operated across other organizations within the same master organization. Additional details are covered in the section Program Modeling below.
Modeling a single asset vs multiple assets in a single work requirement	An asset can be modeled independently in a work requirement, or together with similar assets. Additional details are covered in the Work Requirement section below.
Suppress and Merge across Work Requirements	While supported across work requirements, we generally recommend only using merge and suppress within a work requirement. Therefore, it's recommended to disable the capability of suppress and merge across work requirements. See the How You Model the Merging and Suppressing of Work Definitions topic to learn more.
Initialize assets for day and meter forecasts	The first due date for an asset should be calculated based on the last completion in your prior system when using a day or meter interval. Else, the system won't have an anchor date and interval, if applicable, to calculate the next due. It's recommended to initialize your assets by setting a historical last completed date and interval value, if applicable, and a forecast start date. If you're using a meter, it's recommended to include a meter reading in history as of this historical completion date, else the forecast has to calculate back to establish a baseline, which can result in overdue forecast lines in the past. Setting a forecast date of today or a future date also helps to establish the forecast as well, since it's considered instead of the requirement’s start date. See the Asset Initialization topic, How You Create a Work Requirement section to learn more about both the existing and Redwood pages, and the section How You Manage Maintenance Forecasts.
Consider last completion option for day and meter forecasts	The next due date for a day and meter forecast is recommended to be calculated based on the last completion date. If your business exceeds the next interval, you may want to dynamically push future due dates when the forecast recalculates. See How You Manage Maintenance Forecasts to learn more.
Generate forecasts for a work requirement, or an asset within a requirement	When creating or editing a work requirement, it's helpful to generate its forecast to confirm the modeling and asset initialization. Instead of generating the forecast for an entire program, which can be time consuming, it's recommended to only generate it for a work requirement, or an asset within a requirement. The forecast quickly updates, allowing you to verify the results. These actions are only available if you disable the capability of suppress and merge across work requirements. Additional details are covered in the section How You Model the Merging and Suppressing of Work Definitions. Note: It is generally only recommended to run the Generate Maintenance Forecast process for a program only on a scheduled basis. Care should be taken manually running this process for an individual program. Additional details are covered in the section How You Manage Maintenance Forecasts.
Generate a forecast preview prior to promoting a work requirement and assets to planning	If the opt-in is enabled, a new status Ready to Forecast becomes available when using the Redwood pages. This status allows you to generate a forecast preview and validate your requirement modeling and asset initialization in the Forecast tab. This gives you the ability to fine tune the settings until you are satisfied with the outcome. Promoting the requirement to planning will release the forecast for viewing in the Manage Forecasts page and allow the due dates to create work orders. Additional details are covered in the section How You Manage Work Requirements in a Maintenance Program, covering the Redwood pages, and the section How You Manage Maintenance Forecasts.
Generate Maintenance Forecasts Processing Time	For large data sets, it's helpful to enable parallel processing and to also set the number of concurrent processing workers. See How You Manage Maintenance Forecasts to learn more.

Program Modeling

Programs are always created in the context of a specific maintenance-enabled organization. But, before you create any programs, consider if the program manages only the assets operating in the same organization or it also considers assets that are operated across other organizations within the same master organization. Also consider if these assets remain in the same operating organizations over time, or they may be transferred to another operating organization at some point in the future.

Here is some guidance for modeling maintenance programs:

#	Scenario	Recommendations on Program Modeling
1	If an asset is operated and maintained in the same maintenance organization	Create a maintenance program that considers assets in the same organization only.
2	If an asset is operated in a non-maintenance organization and is maintained by one or more organizations over time	Create a program that is enabled for cross-organization assets. See the last row in this table for more details.
3	If an asset is currently operated in a maintenance organization but may be operated and maintained in different maintenance organizations over time	Create a program that is enabled for cross-organization assets. See the last row in this table for more details. While maintenance organization relationships aren't required to maintain an asset using a maintenance program, if you maintain assets across organizations you need to enable the program. This allows you to optionally update the work order organization in the Manage Forecasts page.
4	If an asset is operated in a maintenance organization, but may be transferred to another operating organization during its lifetime	Create a program that is enabled for cross-organization assets. Organization relationships are helpful if you wish to maintain assets that operate in non-maintenance-enabled organization in a specific maintenance organization. By default, assets in the organizations that are maintained in a program, enabled for assets across organizations, are forecasted and have work orders created in the program’s organization. If you want an asset to be maintained always in a single maintenance organization, you can define a support as primary relationship between the non-maintenance-enabled-organization and a maintenance organization. This ensures that 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. See the How You Create Maintenance Programs topic to learn more. Note: If you decide to create a cross-organization program, define a single maintenance organization that can be designated as the central planning organization. While you can create cross-organization programs in any maintenance organization, modeling them in a single organization will reduce complexity and improve visibility. Note: Avoid modeling preventative maintenance for a unique asset using both methods at the same time, as it can be difficult to manage same asset across programs or organizations.

For item-based work requirements, if the program is enabled for enabled for cross-organization assets, then you can decide if the work requirement will automatically or manually include assets that operate in other organizations. Regardless of the asset inclusion method selected, you can always include or exclude assets from the work requirement using the affected assets page. Therefore, even though a program is enabled for cross-organization assets, you ultimately can control which assets will be forecasted and considered for work order creation over time.

If the opt-in is enabled, you can optionally define a work requirement using mixed assets. This gives you the ability to decide exactly which assets are included, even though they have different items. The rest of the capabilities are the same as an item-based work requirement.

Forecasts are always created based on where an asset is operating at that point in time. For assets operating in a maintenance organization, work orders are expected to be created in the same organization. Assets operating in a non-maintenance organization will be maintained in a different maintenance organization. After a forecast due date is generated, and before a work order is created, you can recommend an alternative due date or work order organization if the program is enabled for cross-organization assets. These requests can be submitted using the Manage Forecasts page or REST API for a specific forecast due date. This capability will help planners adjust to short-term changes in an asset’s maintenance availability or short-term assignment to a different organization. Additional details and validations are covered later in the section entitled How You Manage Maintenance Forecasts.

Note: Forecasts created for a program that is enabled for cross-organization assets will use the contextual organization calendar for the forecast. If assets operate in organizations that use different calendars, then they aren't be considered until work order creation. Therefore, the forecast may produce due dates on non-working days for the asset’s organization.

Once a program creates its first work order, the option to enable or disable a program for cross-organization assets can’t be updated. Therefore, if there is a chance that assets may be maintained in different maintenance organizations over time or asset may transfer organizations, you should enable the program for cross-organization.

Work Requirement

You can create work requirements for each service interval task, or even a group of related service interval tasks for one or more assets. The tasks define how often the service is required, the expected resource and material requirements, and the steps required to complete the task. A work requirement is first created in a status of Draft. Once you have defined the header, forecast method, assets, and work definitions, it moves to a status of Ready to Forecast (if the opt-in is enabled) or Active. You can edit but not delete a work requirement after the first work order is created for the work requirement. Optionally, you can end date a requirement to stop forecasting.

A work requirement can be defined to apply to an asset, item, list of assets, or an asset route. For an item-based requirement, you decide if all or only certain assets will be forecasted. An item-based requirement resolves to an asset level in the forecast, so you can define a common work requirement for one or more assets. This includes assets in the context organization as well as across organizations. A mixed asset-based requirement, only available through opt-in, allows you to manually define a list of assets based on the same or different items, either in the same organization or across organizations.

Here is some guidance for modeling an individual asset within a work requirement:

Advantages	Disadvantages
You can define modeling options that are unique to the asset. You can stop, adjust, and restart the forecast, with some limitations. Modeling meter-based forecasts is easier, as you have increased visibility to the asset’s meter history, making initialization easier. If your current system individually models each asset, then implementation may be simplified.	For similar assets that are maintained in the same location, maintaining multiple requirements may be time consuming to create and maintain, creating additional overhead. Visibility for modeling the sequencing of common maintenance across similar assets requires additional effort.

Here is some guidance for modeling multiple assets within a single work requirement using an item-based, or if the opt-in is enabled, using mixed assets:

Advantages

Disadvantages

Modeling common inspections or preventative maintenance for multiple assets in a single requirement will save time, overhead and provide better visibility.
Using an item-based requirement, you can easily control which assets are included or excluded from the requirement.
Using a mixed asset requirement, you can easily model similar assets, based on different items, in the same requirement.
If your current system individually models each asset, then you can take advantage during implementation to simplify your modeling and combine into a single requirement.

You have limited modeling options that are unique to the asset.
Modeling meter-based forecasts is supported, but you as you have decreased visibility to the asset’s meter history, requiring additional effort for initialization and forecast verification.

The requirement's start date is used to define the first date from which a forecasted due date is calculated. Typically, this date is set in the future, but it can also be set in the past to set the sequence of intervals of a cycle-based forecast for some scenarios.

For each work requirement, you will define a forecast method. This can be based on a calendar pattern, day interval, utilization meter. You can even have competing methods, such as Calendar vs Meter or Day Interval vs Meter, using a whichever comes due first rule. A requirement that has only a condition event defined will not be forecasted.

One or more work definitions are then associated to a work requirement. If using a cycle-based forecast, you can define on which intervals each work definition is due. Use the concurrent requirements option to define whether you want to suppress or merge the work requirements on over lapping intervals in a cycle.

The work requirement is used as the basis for generating a forecast for the associated work definitions, allowing you to validate your forecast method, and then it's ready for creating work orders. By design, it's expected that each work requirement creates a unique work order for each due date in the forecast for an asset. This work order could be based on one or more work definitions, as defined in the work requirement, over time. Therefore, it's important to understand how to translate service intervals into a work definition and then further model its frequency in a work requirement.

Asset Route

Asset routes allow you to centrally plan, execute and record maintenance for a collection of assets using a single work order. Asset routes are useful for repetitive or routine maintenance such as inspections or preventative maintenance, eliminating the overhead of creating multiple work orders for the same activity.

Asset Routes aren't recommended in cases where you need to model, forecast, plan and record individual work order accomplishments for each asset in the collection. You won't see any due dates in the Maintenance Forecast page for assets within a route. All service history for the collection of assets in a route is only available via the work order details and OTBI reporting, as the accomplishment of the preventative maintenance is only tracked at the route asset level.

Also, the work performed in an asset route work order should be limited, as any resources or materials are charged for costing purposes against the work order asset, not individually against the assets in the collection. Only through cost reporting, you can add costs at the collection asset level.

For example, here are a few use cases where you can use asset routes:

Inspect and maintain Fire extinguishers in each floor of a building.
Maintain hospital beds by room in each ward of a hospital.
Perform basic preventative maintenance on forklifts in a production facility.

These are some examples where it isn't recommended to use an asset route:

5-year refill and recertification of a fire extinguisher.
Yearly certification of an individual hospital bed by a qualified technician.
Periodic replacement of hydraulic cylinder in a forklift.

Routes are:

Defined using a logical hierarchy.
Forecasted using a maintenance program.
Managed using the Maintenance Supervision page.
Recorded for compliance in the My Maintenance Work page.
For now, routes aren't supported in a manually created work orders.

To get started, model these assets:

An asset that represents the collection of assets. This can be an asset that represents a physical location such as a plant, building, floor, or a production line. Or it could be a specific asset that is created to manage the collection itself. This asset is forecasted by a preventative maintenance program and is used to create maintenance work orders. Therefore, it's recommended to name it something that represents the collection of assets being maintained by the asset route.
Assets in the collection of assets. These are maintainable assets that are referenced in the asset route but can also be individually maintained via regular preventative maintenance or adhoc work orders.

After this, create a logical hierarchy. See the Assets chapter for more details.

Asset Initialization

For all work requirement types, when introducing a new forecast for an asset, you will need to understand how the first due date will be calculated.

In general, a requirement will start calculating from its Start Date. Setting a date in the past, present, or future will yield different results. It is important to know how you can calculate the first due by providing the last date and interval, if applicable, in which maintenance was performed in your legacy system or to help establish a cadence for a newly introduced asset. Additionally, entering in historical meters readings that relate to these dates are also important to generate the first due date for an asset in a work requirement.

These considerations are covered in the section How You Create a Work Requirement for both the existing and Redwood pages, and the section How You Manage Maintenance Forecasts.

Forecast Preview

If the opt-in is enabled, you can optionally generate a forecast preview to confirm your modeling criteria if the requirement is in the Ready to Forecast status. This status allows you to optionally generate a forecast preview to confirm your modeling criteria. This preview can only be viewed in the requirement and not shown on the Manage Forecasts page as the dates won't be available for work order creation. This capability allows you to finetune your modeling, reforecast as many times as are needed to confirm your criteria. Once you're satisfied, you can release it to planning and it moves to the status of Active, allowing it to be viewed in the Manage Forecasts page be available for work order creation. Additional details are covered in the section, How You Manage Maintenance Forecasts.

Tasks

As part of maintenance program, you can perform these tasks:

You can create and edit a maintenance program.
You can create multiple work requirements for a maintenance program.
You can create a calendar pattern and associate it with multiple work requirements in the same program.
You can generate the maintenance forecast in the context of a program using a scheduled process.
You can generate the maintenance forecast in the context of a program for a work requirement or asset in a work requirement, using actions from the program pages. To enable these actions, your administrator must set the Allow Suppress and Merge across Work Requirements parameter in a Maintenance Program to No.
You can view the maintenance forecast in a Gantt chart or calendar. You can also search and restrict information to be displayed on the Gantt chart. This is used to confirm the forecasting methods and intervals are correctly aligned with the preventative maintenance schedule that's desired.
You can also do the maintenance forecast in the Manage Forecasts page. You confirm the forecasting methods and intervals in a results view. You can optionally request an alternative due date or location for a forecast due date, skip a due date, as well as create or cancel work orders.
You can further review the forecast by creating a report or analysis using OTBI. For more details, refer to the Reports and Analytics chapter of this guide.
You can create maintenance work orders in the context of a program using a scheduled process. You can then view the details in the Gantt chart or calendar.
You can automatically create maintenance work orders based on the forecast using a scheduled process.
After the forecast is confirmed, the best practice is to automatically create the maintenance forecast and work orders using a scheduled process. This program should be scheduled to run frequently to create work orders for execution.