This chapter covers the following topics:
The spares forecast, whether from Enterprise Resources Planning (ERP), or from demand planning systems, or generated within SPP can be entered to planning as a demand schedule. Generating forecasts within SPP is termed inline forecasting.
The following topics refer to inline forecasting:
Many variables such as usage pattern, asset population, service product life cycle, and failure rate affect demand. Oracle Service Parts Planning supports forecasts based on the following data streams:
Spare part shipment history
Spare part usage history
Spare part returns history
Spare product returns history
Product population and failure rates
* Forecast level –
Generate the local forecast for an item if the item has a forecast policy assigned at the organization level.
Generate the global forecast for an item if the item has forecast policy assigned at the zone level
Generate both local and global forecasts for an item, if the item has forecast policies assigned to both organization and zone levels. Use this approach to generate forecasts based on complete data when one service operation offers repair services by field technicians (collecting field spares usage) and repair services at internal depots (collecting the history of issues to internal repair orders).
You specify which historical data stream to use as the basis of the forecast in the Forecast Rule. In planning, internal sales orders (outbound shipments) to organizations that are not included in the Plan Options, and shipments to field technician organizations, are considered as shipment history. Such shipments typically include those outbound from a distribution organization to the field organization, or where applicable, directly to external customers.
To avoid double counting, the history stream includes shipments to field technician organizations, but not to distribution organizations. In the case in which the scope of the plan is limited to only the central warehouse, then the history basis should include all outbound shipments from the central warehouse.
SPP collects two data streams for shipment-based forecasts:
Internal sales order outbound shipments, for which the destination organizations are field technician organizations. The field technician organizations are specified in the Collections setup window. Note that outbound shipments that are not shipped to the field organizations should not be part of the history.
The following information is used as part of the history:
Item, ship date, source organization, destination organization, quantity shipped, and unit of measure (UOM).
Internal sales orders (ISOs) and their corresponding internal requisitions are collected. ISOs do not have a destination organization. The Ship to is for an external location. Thus, in order to determine the destination organization for an ISO, it is necessary to link to the internal requisition. The organization in which the internal requisition is created becomes the destination organization.
Data stream definition details
Source Type: ERP
Type of data: quantity
Dimension levels
Product: Item
Ship From: Organization
Ship To: Organization (local forecast based on the source organization)
Geography: NA
Time: At day level only
Make sure that the technician organizations are not named as planned organizations in the plan options. If they are planned, then they are considered as distribution organizations, and the corresponding history is ignored for forecasting purposes.
Similarly, if any of the distribution organizations from which history has been collected are not planned in the plan, then such history data is also omitted.
For example, the central distribution center has outbound shipments to field technician organization, and the history has been collected. However, in the plan options, the central distribution center is not being planned. Then the corresponding history of the central distribution center is not considered for forecasting purposes.
Sales orders to external customers based on the shipment history.
The following information is used as part of the history:
Item, Organization, ship date, quantity shipped, and UOM
Data stream definition details
Source Type: ERP
Type of data: quantity
Dimension levels
Product: Item
Ship From: Organization
Ship To: Organization
Time: At day level only
Historical material usage data captured as part of the Oracle Spares Management Debrief process is used to project the future parts requirements for technician organizations. Spare part item historical usage from technician organizations is calculated at the zone level. The zone is based on the location tied to the technician trunk stock (or subinventory) from which the field service usage occurs.
For supply planning, these forecasts are considered as global forecasts. You specify global sourcing rules to push this forecast to the appropriate replenishing organization.
Service part usage history is collected from Oracle Field Service usage transactions created in the Spares Management Debrief process.
This process collects the following information:
Service part replaced (Item ID)
Date replaced
Quantity replaced
Customer location (at zone level)
Data stream definition details
Source Type: ERP
Field Service: Collect only ‘field service usage transactions’ created through the Oracle Spares Management Debrief process.
Type of data: Quantity
Dimension levels
Product: Item
Ship From: Organization
Ship To: Zone
Time dimension: At day level only
Spares requirement forecasts can also be based on the historical consumption of parts in depot repair organizations by collecting the history data of component issues against repair work orders at the depot organization. Such forecasts are generated at the depot organization level.
Service part usage history is collected from Oracle Depot Repair material requirements for repair orders or Java Technology Framework.(JTF) tasks.
The following information is collected:
Service part replaced (Item ID)
Date replaced
Quantity replaced
Customer location (at zone level)
Data stream definition details
Source Type: ERP
Depot Repair: Collect the material requirements and job quantities for repair jobs. Repair jobs are non standard discrete jobs created in Work in Process (WIP) that are based on repair orders in Oracle Depot Repair. Also collect material requirements from JTF tasks.
Type of data: quantity
Dimension levels:
Product: Item
Ship From: Organization
Ship To: Organization level
Time dimension: At day level only
The seeded methods for calculating returns include:
Returns-based forecasts capture the history of service part and product returns from Oracle Field Service and from Order Management RMAs. That information forms the basis for projecting future returns. Thus, forecasts for total returns depend on:
Returns of service parts from field technicians
Direct returns of service parts from customers, through the RMA process
Direct returns of products from customers, through the RMA process.
Field service returns are fed into the planning process as a global returns forecast at the zone level. Planners can assign the Return to sourcing rule to push the field service part returns forecast to the appropriate returns organization according to the business process.
Only field service recovery transactions created through the Field Service Debrief process are collected.
Data stream definition details:
Source Type: ERP
Type of data: quantity
Collect the following information from Field Service tables
Defective service part (Item ID) returned
Return date
Quantity returned
Customer location (at zone level)
Dimension levels:
Product: Item
Ship from: Organization level
Ship to: Zone level
Time: At day level only
Service parts can also be returned directly through the RMA process. Defective spare parts returned from customers through the Order Management RMA process are entered to the planning process at the repair organization.
Use the Include RMA Type field to select the types of RMAs to be collected:
All (default): Returns for all RMA types are collected
Replacement, Receipt and No Credit, Receipt and Credit, and Repair RMA
RMAs of the type called RMA with Credit Only are not collected.
Data stream definition details:
Source Type: ERP
Type of data: quantity
The following data is collected from Oracle Order Management as part of the direct returns:
Defective service part (Item ID) returned
Organization
Customer location
Return date (Date on which the RMA is created)
Quantity returned
Dimension levels:
Product: Item
Ship from: Organization (local forecast)
Ship to: Organization (local forecast)
Time: At day level only
Note: Returns orders are sales orders with Line Type Return and negative quantities.
In many cases, customers directly return products through the Order Management RMA process. These products yield defective service parts when disassembled or dismantled for repair. This stream of defective parts is considered while forecasting the returns. The amount of service parts yielded by a product depends on the average failure rate of the service parts within the given product. The failure rate for the product and service part combination is determined as described in the procedure: Setting Up Install Base, Failure Rate, and Retirement Rate.
The history of product returns is collected and projected. The projected product returns are then multiplied by the service part-specific failure rate to determine the projected service part returns. The total returns for a given service part is equal to the sum of all the returns from the corresponding products with which product and service part relationships are established.
Solution Overview
The solution consists of the following components:
Collection of product returns history – Order Management order type: RMA.
Projection of the future product returns, based on history. The forecasting method is specified in the forecasting rule associated with the product.
Multiplication of the projected product returns by the failure rate, to project the quantity of service part returns.
Returns for service part (i) in bucket (t) = SUMj=1,n (Returns for product (j) in bucket (t) * failure rate (i,j))
Where:
(i) is the service part belonging to product (j)
n is the number of products with which the service relationship is enabled (as defined in the setup > product population forecasting parameters form)
Assumption:
The defective service parts are assumed to be available in the same bucket as that of the returned Product. In reality, there is a lag between the return of the product and the availability of the service part. However, for simplicity, the events are assumed to occur simultaneously.
You specify the following two major components as part of the forecasting rule, in the Usage/Shipment/Returns tab:
Select the history basis Product returns
Specify forecast parameters, such as Forecast method and Horizon for projecting future product returns.
Use the Include RMA Type field to select the types of RMAs to be collected:
All (default): Returns for all RMA types are collected
Replacement, Receipt and No Credit, Receipt and Credit, and Repair RMA
RMAs of the type called ‘RMA with Credit Only’ are not collected.
Data stream definition details
Source Type: ERP
Type of data: quantity
Dimension levels
Product: Item
Ship from: Organization
Ship to: Organization
Time: At day level only
If the return history is collected for an item that is a product, as defined in the service relationship, and if the forecasting rule has product returns as the history basis, then product return-specific calculations are performed. If the return history is collected for a service part, then the item return history is projected.
The returns forecast can be made up of field technician returns, direct service part returns, and yields from direct product returns. However, the breakdown of each of these streams is not visible to the user. The user sees one number that is the aggregation of all the return sources. The product population-based returns (return rate forecast) is visible as a separate row.
If the failure rates of service parts are known along with the overall product population, you can use that information as a basis of forecasting the demand and supply of the service parts. The overall product population is composed of the current products in service and future or anticipated products to be serviced. To determine the product population accurately, retirements (when products are taken out of service) also need to be taken into consideration. Failure rates are typically age dependent, and can vary according to the product’s life cycle stage.
Main Components
The main components of Product Population-based forecasts are:
Oracle Install Base history: Time-phased Install Base history collected from Oracle Installed Base is used in calculating the current installed base and failure rates.
Current Install Base population: This constitutes the total of active currently installed products. This information is obtained in one of two ways:
User specified: The user provides a value for the currently installed base, or
Calculated from Oracle Install Base: This value is calculated from the collected Oracle Install Base population history stream.
Projected product population: This population is based on the installed base information, and is calculated according to the following equation:
Installed base (t) = {Installed base (t-1) + [sales forecast (t) * service market share] * periodic survival rate}
Where Installed base (t) represents the current installed base value.
Failure rates: This denotes the average periodic failure rate of the product population. You specify an average (non time varying) failure rate for a product and service part combination.
Determining the projected demand for service part: Once the projected population and the failure rates are known, the demand for the service part for a time period (t) can be projected:
Projected demand for service part (i,t) = SUMj=1,n (projected product population (j,t) * failure rate (i,j))
where,
i is the service part being used in product j
n is the total number of products using service part i
Oracle Install Base can be used to track products and assets at a customer site, and can represent the total number of serviceable products in the field. Retirements of products need to be taken into account to arrive at accurate install base numbers.
Year | 2003 | 2004 | 2005 | 2006 | 2007 |
---|---|---|---|---|---|
New installed base | 100 | 120 | 110 | 125 | 120 |
Retirements | 0 | 0 | 0 | 50 | 100 |
Net installed base | 100 | 120 | 110 | 75 | 20 |
Data stream definition
Name: Install Base History
Source Type: ERP
Type of data: quantity
Allocation: not allowed
Dimension levels
Product: Item
Ship From: Not applicable
Geography: Not applicable
Time: Two dates exist—installation date and end active date
Sales Channel, Sales Rep, and User-defined dimensions: Not applicable
The following information is collected from Oracle Install Base tables:
Product
Owner party ID
Installation date
End active date (decommissioned on this date)
Quantity
Collection is done for installed base at external customer sites only. When a customer name is associated to the product (Owner party ID other than Internal as defined in install parameters), it becomes part of the external installed base. Further, if the installed base date is blank or null, then the product is possibly returned for major repair, or has been returned permanently. Such rows are ignored.
When lot control is enabled to track the install base, the quantity can be more than 1. When a product (an item instance) of the lot is retired, the lot is split in Install Base such that only the retired product bears the end active date. In the example data, rows 2, 3, and 4 represent a lot quantity of five, two of which have been retired.
Collections brings both active and retired install base; however, the retired install base is filtered out. The following table shows whether the data rows are filtered out:
Product | Owner Party ID | Installation Date | End Active Date | Qty | Filtered out? (Yes or No) |
|
---|---|---|---|---|---|---|
1. | Printer AT | Zinc Inc. | 01-APR-2007 | None | 7 | No |
2. | Printer AT | Zinc Inc. | 04-JAN-2006 | 31-JAN-2007 | 1 | No |
3. | Printer AT | Zinc Inc. | 04-JAN-2006 | 10-DEC-2006 | 1 | Yes. Product retired before history start date. |
4. | Printer AT | Zinc Inc. | 10-JAN-2007 | None | 3 | No |
5. | Printer AT | Red Inc. | 07-APR-2007 | None | 5 | No |
6. | Printer AT | Internal | 05-JAN-2007 | None | 2 | Yes, not external |
7. | Printer AT | Red Inc. | None | None | 1 | Yes, possibly returned |
8. | Printer AT | Red Inc. | 15-FEB-2007 | None | 5 | No |
Finally, the information appearing in the Forecast Analysis View is aggregated at the product level, and bucketed according to the forecast bucket size specified in the Plan Options. For example:
Calendar: Gregorian
History start: 01-JAN-2007
History end: 31-MAY-2007
The preceding history information is summarized into monthly buckets as shown:
Product | Quantity | Period | Comments |
---|---|---|---|
Printer AT | 4 | JAN-2007 | Product is assumed to retire instantaneously at the end of the period. |
Printer AT | 8 | FEB-2007 | |
Printer AT | 8 | MAR-2007 | Same as February, because there were no new installations or retirements |
Printer AT | 20 | APR-2007 | |
Printer AT | 20 | MAY-2007 |
Collection Parameter
The parameter Install base history appears on the Collection window with the LOV value Yes or No, to provide flexibility to collect or not collect the Install Base history.
Current Installed Base Population
The currently installed base population acts as the basis for the projected installed base. If Oracle Install Base information is available, it is computed as follows:
Current install base = (total install base population to date - retirements to date)
Year | 2001 | 2002 | 2003 | 2004 | 2005 | Total |
---|---|---|---|---|---|---|
New installed base | 100 | 120 | 110 | 125 | 120 | 575 |
Retirements | 0 | 0 | 0 | 50 | 100 | 150 |
The current installed base in this example is equal to (575 – 150) = 425.
If the Oracle Install Base information is not available, you can enter this information directly through the user interface, or by using mass upload capabilities.
Projected Product Population
The projected product population is typically based either on the Install Base history or on the current Install Base plus sales forecast.
Projecting product population based on Install Base history:
You can choose to project the Product Population based on the Install Base History. In that case, you select the appropriate forecast method, and set the horizon to be considered for forecasting.
Projecting product population based on sales forecast:
Because not all product sales translate into a service contract, you can adjust the sales forecast to provide an estimate of the service market share. A factor called the Service Adjustment Factor is provided to adjust the sales forecast accordingly. The projected product population is computed as follows:
Installed base (t) = [installed base (t–1) + sales forecast (t) * service adjustment factor] * (1 - retirement rate)
Note: Installed base (t = 0) is equal to the current installed base.
Estimating sales forecast:
If the sales forecast is already available, you can use it directly. Two available options are:
Flat file loads (presented as a demand schedule)
Demand planning and ERP forecasts
Optionally, you can directly enter the projected population (if known), set the service adjustment factor to 1 (or leave it blank), and set retirement rate to zero (or leave it blank).
If the sales forecast is not available, you can generate the sales forecast, and use it in the calculation of the projected product population. This generated sales forecast is solely for the purpose of calculating the projected product population, and is not available to be viewed in the user interface or available for subsequent use.
You can collect sales order booking history and shipment history as part of the collection parameters. The data is collected at the day level for the range specified in the global parameters.
The following sales order data is collected:
Item
Instance and Organization
Booked date
Shipped date
Quantity
Unit of measure
The sales forecast is done according to the specified forecasting parameters. The history range, forecast horizon, calendar, and bucket are selected from the Horizon Details tab of the Forecast Rule window. You can specify whether booking history or sales history should be used. The forecasting engine considers the appropriate dates.
Forecasting is done at the organization level only (local forecasts). After the system generates local forecasts, the information is aggregated at the global item level. That is, all the organization level quantities are summed for a given item. Once the sales forecast at the global level is determined, subsequent calculations project the installed base.
Products are retired after their useful life and taken out of the installed base. Thus you must account for the retirement rate in order to determine the projected population accurately. It is common business practice to keep track of the average periodic product retirement rates. This is typically expressed in terms of a percentage of the overall product population that retire during a given time period (or bucket).
The retirement rates must be entered at the same time bucket level as that of the product population forecast. The retirement rates are non time varying. This means that the same rate applies for the entire forecast horizon.
For example:
Product: Printer A
Service Adjustment factor: 60%
Retirement rate: 10% (therefore, the survival rate is 90%)
Current installed base: 100
Year | 2006 | 2007 | 2008 |
---|---|---|---|
Sales Forecast | 240 | 280 | 350 |
Serviceable products (after applying the 0.6 service adjustment factor) | 144 | 168 | 210 |
Total serviceable products (after adding the previous period’s 100 installed base) | 244 (144+100) |
387 (168+219) |
558 (210+348) |
Projected Installed base (after applying the 10% retirement rate) | 219 | 348 | 502 |
Failure rate information can be based on many factors such as usage, product life-cycle patterns, and reliability characteristics. This section focuses on usage-based failure rates obtained directly from users.
In cases in which the install base information is inadequate, you can directly enter the average periodic failure rate for a product and service part combination. For example:
Printer A - Cartridge x: average failure rate is 10.7% per time bucket.
Printer B - Cartridge x: average failure rate is 1.73% per time bucket.
The example shows that a service part, such as cartridge x, can have a different failure rate in the different products that the service part is assigned to. The Failure Rate window accessed by navigating Service Parts Planning > Setup > Failure Rate, enables you to set up failure rates for product and part combinations.
The failure rate is expressed as an average percentage of the population that fails per unit of time. The unit of time must be equivalent to the product population forecast time bucket size. In other words, if the product population forecast is in weekly buckets, then the failure rate is expressed in percent per week. The average failure rates are non-time-varying, meaning that the specified failure rate applies for the entire forecast horizon.
See Setting Up Install Base, Failure, Return, and Retirement Rates.
Demand for service parts vary with the installed base population and service part-specific average failure rates, according to the following equation:
Projected demand for service part (i,t) = SUM,j=1,n (projected product population (j,t) * failure rate (i,j))
where,
i is the Service part being used in product j
n is the total number of products using service part i
Continuing from the previous example:
Cartridge x is used in both Printer A and Printer B
Average failure rate for Printer A – Cartridge x: 0.107
Average failure rate for Printer B – Cartridge x: 0.0173
Year | 2006 | 2007 | 2008 |
---|---|---|---|
Projected Printer A Install Base | 219 | 348 | 502 |
Cartridge x – Printer A projected failures | 23 | 36 | 53 |
Projected Printer B Install base | 527 | 658 | 807 |
Cartridge x – Printer B projected failures | 9 | 11 | 13 |
Total cartridge x projected demand | 32 | 47 | 66 |
You can compute the return forecast of the service parts based on the return rates and the corresponding product population. The calculations are similar to those of the Product Population based forecasting, except that returns history is used instead of the usage history, and return rates are used instead of failure rates.
User-Specified Return Rates
You enter the average return rates on the Failure Rate window. Once the average return rates and the corresponding product population are known, the returns can be forecast using the following equation:
Return forecast for service part (i,t) = Sj=1,n (projected product population (j,t) * return rate(i,j))
where,
i is the Service part being used in Product j
n is the total number of products using service part(i)
See Setting Up Install Base, Failure, Return, and Retirement Rates.
This profile option determines the number of processes that are launched in parallel for forecasting. Configuring multiple processes can speed up forecasting.
From the Service Supply Chain Planner responsibility, navigate to the Profile window.
Other > Profile
The Personal Profile Values window appears.
. In the Profile Name column, inquire on Profile “MSC:Number of processes for Inline Forecast”
Enter the number of processes.
Click Save.
In addition to generating "inline" forecasts in SPP, it is also possible to generate a forecast for Service Parts in Demantra and use that forecast in SPP. For more information, refer to Service Parts Forecasting in the Oracle Demantra Demand Management User Guide.
For implementation information and processes on collecting data for Demantra, refer to "Demantra Demand Management to EBS Integration" and "Demantra Demand Management to EBS Collecting Source Data Service Parts Planning Integration" chapters in the Oracle Demantra Implementation Guide.
As mentioned, Demantra can generate a forecast for Spare Parts, which can then be used in SPP. While generating a Service Parts Forecast, Demantra can consider the Install Base of products under contract, and the serviceable parts (field replaceable units) in each of these. It can then calculate the failure rate for each of these parts in the product, and generate a forecast for the parts, based on the projected install base of the products. For more information, refer to Service Parts Forecasting in the Oracle Demantra Demand Management User Guide.
For implementation information and processes on collecting data for Demantra, refer to "Demantra Demand Management to EBS Integration" and "Demantra Demand Management to EBS Collecting Source Data Service Parts Planning Integration" chapters in the Oracle Demantra Implementation Guide.