Forecasting Concepts

This chapter covers the following topics:

Inline Forecasting Concepts

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:

Supported History Data Streams

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:

Supported Inline ForecastsInline ForecastSupported Types
Forecast Base Forecast Source Forecast Level *
Shipments Outbound shipments from distribution organizations (includes both internal sales orders and sales orders) Local
Usage Field technician usage Global – Zone
Usage Depot Repair usage Local
Returns Field technician returns Global – Zone
Returns Return Material Authorizations (RMA) in Order Management for service parts Local
Returns RMA in Order Management for products Local
Population Projected Oracle Install Base population with applied part failure rate Global
Population Current Oracle Install Base population and product sales forecast, with applied part failure rate Global

* Forecast level –

Spare Parts Demand Forecasts Based on Shipments

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.

Data collection.

SPP collects two data streams for shipment-based forecasts:

  1. 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.

  2. 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

Spare Parts Demand Forecasts Based on Usage

Forecasts Based on Field Technician Usage

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.

Data collection

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:

Forecast Based on Depot Repair Usage

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.

Data collection

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:

Spare Parts Supply Forecasts Based on Returns

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:

Field Service Returns

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.

Data collection

Only field service recovery transactions created through the Field Service Debrief process are collected.

Data stream definition details:

Collect the following information from Field Service tables

Spare Part Returns Through Order Management RMAs

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.

Data collection

Use the Include RMA Type field to select the types of RMAs to be collected:

Data stream definition details:

The following data is collected from Oracle Order Management as part of the direct returns:

Note: Returns orders are sales orders with Line Type Return and negative quantities.

Product Returns Through Order Management RMAs

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:

  1. Collection of product returns history – Order Management order type: RMA.

  2. Projection of the future product returns, based on history. The forecasting method is specified in the forecasting rule associated with the product.

  3. 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:

Data collection

Use the Include RMA Type field to select the types of RMAs to be collected:

Spare Parts Demand Forecasts Based on Product Population

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.

Solution Overview

the picture is described in the document text

Main Components

The main components of Product Population-based forecasts are:

Forecast Service Product Demand Based on Install Base

Oracle Install Base history

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.

Example: Installed Base for Printer A
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

Dimension levels

Data collection

The following information is collected from Oracle Install Base tables:

Install Base example data:
Product Owner Party ID Installation Date End Active Date Quantity
Printer AT Zinc Inc. 01-APR-2007 None 7
Printer AT Zinc Inc. 04-JAN-2006 31-JAN-2007 1
Printer AT Zinc Inc. 04-JAN-2006 10-DEC-2006 1
Printer AT Zinc Inc. 04-JAN-2006 None 3
Printer AT Red Inc. 07-APR-2007 None 5
Printer AT Internal 05-JAN-2007 None 2
Printer AT Red Inc. None None 1
Printer AT Red Inc. 15-FEB-2007 None 5

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:

Collected Install Base example data, with History start date 01-JAN-2007.
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:

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  

See Forecast Analysis View.

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.

Estimating sales forecast:

If the sales forecast is already available, you can use it directly. Two available options are:

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:

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.

Retirement Rate

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:

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

Determine Service Part Failure Rates

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.

User-Specified Failure Rates

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:

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.

Forecast Service Part Demand:

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:

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

Projected Returns of Service Parts:

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.

Setting the MSC:Number of processes for Inline Forecast Profile Option

This profile option determines the number of processes that are launched in parallel for forecasting. Configuring multiple processes can speed up forecasting.

  1. From the Service Supply Chain Planner responsibility, navigate to the Profile window.

    Other > Profile

    The Personal Profile Values window appears.

  2. . In the Profile Name column, inquire on Profile “MSC:Number of processes for Inline Forecast”

  3. Enter the number of processes.

  4. Click Save.

Demantra Forecasting Concepts

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.

Service Parts Forecasting (SPF)

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.