FIRM and the Packager

Nick T. Thomopoulos

Stuart Graduate School of Business

Illinois Institute of Technology

Consider a distribution-center for an Original-Equipment-Manufacturer (OEM-DC) that orders its stock from a parts-supplier by purchase-orders with data (part, quantity, due-date). Upon completing the fabrication process, some parts, require a subsequent packaging process by a packaging firm (packager) that places the parts in containers with labels and in a way that is friendly for the OEM-DC to store on shelves and to ship.

To carryout this process, the packager holds an inventory of package-components to run its operation. It is the responsibility of the packager to have a systematic way to keep tract of the package-component inventory and to replenish this stock in an efficient way from the packager-supplier. To do this, the packager maintains a bill-of-material on each OEM-part that lists the package-components and the quantity needed to complete one unit of the OEM-part.

The typical packager goal is to hold the minimum package-component inventory that is needed to meet the due-dates assigned to each incoming OEM-part. This is a very challenging task since to complete the function of packaging an OEM-part by due-date and quantity, the proper inventory for each of the package-components in the bill-of-material must be available. Further, the incoming flow of OEM-parts come irregularly with due dates and in lumpy sizes. Also many of the package-components are needed and used on two or more OEM-parts.

This paper considers some typical relations between the OEM-DC, the parts-supplier and the packager. These relations pertain to the part-flow (shipping the stock from one location to another), and to the data-flow (sharing the OEM-part purchase-order data with the packager). The paper also shows how the FIRM routines can be used with any combination of the above scenarios. The goal is to systematically maintain the package-component inventory in a cost efficient manner.

Parts-flow Two scenarios are typical and are described below. For convenience, these are labeled as parts-flow 1 and parts-flow 2.

Parts-flow 1. This is where OEM-DC buys the OEM-parts from the parts-supplier. When ready, the OEM-parts are sent in bulk straight to the packager who -- when finished with the packaging process -- ships to the OEM-DC.

Parts-flow 2. This is where the OEM-DC buys from the parts-supplier. When ready, the parts-supplier ships the stock to the OEM-DC who then sends to the packager. The packager -- when finished -- ships back to the OEM-DC.

Data-flow Two of the more common situations are described below. For convenience, these are denoted as data-flow 1 and data-flow 2.

Data-flow 1. This is when the OEM-DC shares the pending purchase order data (part, quantity, due-date) with the packager. This way, the packager can anticipate the parts and quantity that are subsequently coming to its facility for processing.

Data-flow 2. This is when the packager does not have the purchase-order data. Instead, the packager maintains the demand history on each OEM-part it processes -- and this demand history data is used to forecast the future demands on each part.

This paper shows how the FIRM routines can be used to control the package-component inventory. The methods to use depend on the data-flow and not on the parts-flow. Two methods are described, one for the data-flow 1 and another for data-flow 2.

FIRM routines when Data-flow 1.

In this situation, the packager has access on the purchase-order data (part, quantity, due-date). The method described below applies for parts-flow 1 and parts-flow 2. The FIRM software is installed at the packager, and the routines to use are the following:

Weekly places the oncoming OEM-part schedules by week and quantity on

a table.

SkuOpol finds the order-point and order-level for each combination of OEM-part and package-component.

UnitBuy determines when and how much to buy for each packager-

component. Also finds any excess package-component

stock for candidate return to the packager supplier.

The packager staff maintains data on three FIRM tables called PNOR, skuDetail and unitDetail. A brief description is below:

PNOR table Each record on this table pertains to a pending OEM-part and includes the part, quantity and due-date.

SkuDetail table This table contains the bill-of-material relation between the OEM parts and the package-components (sku). The record includes the following type data: (part, sku, mh, dh). To illustrate, when one unit of a part needs five sku’s in packaging, then mh = 1 and dh = 5; when two units of a part needs one sku, then mh = 2 and dh = 1, and so forth.

UnitDetail table This is a table with the current on-hand and on-order data for each sku (package-component).

The FIRM routines typically run as follows:

Weekly routine This routine is run once a week and establishes 52 weekly buckets with associated weekly dates. The input is the PNOR table and a record for each OEM part on the table is formed. As each pending OEM-part schedule is read, the quantity is placed in the appropriate future weekly bucket for the part. The output is placed in a table called skuWeekly.

SkuOpol routine The routine is typically run in tandem after the Weekly routine. The routine has two input tables: the skuWeekly table and the skuDetail table. This routine serves as an interface between all the pending OEM-parts and the package-components (sku). For each part and sku combination, the computations determine the order-point and order-level by sku. The results are placed on the skuDetail table.

UnitBuy routine This routine is typically run daily (sometimes weekly) with input from the skuDetail table and the unitDetail table. The computations combine the relation between every OEM-part and package-component to determine the order-point and order-level for each package-component. The output identifies when a package-component needs a buy and the associated buy quantity. The routine also identifies excess stock and lists candidate return quantities.

FIRM routines when Data-flow 2.

In this situation, the packager does not have access to the purchase order data (part, quantity, due-date). Instead, the packager maintains the inflow of the OEM-part demand history and uses this data to forecast the future demands of the OEM-parts at the packager. The method described below applies for parts-flow 1 and parts-flow 2.

The FIRM routines that apply are the following:

Forecast-Replenish (FR) forecasts the OEM-part demands to the packager for

the coming months.

SkuOpol finds the order-point and order-level for each combination of OEM-part and package-component.

UnitBuy determines when and how much to buy for each packager-

component. Also finds any excess package-component

stock for potential return to the packager supplier.

The packager staff maintains data on three FIRM tables called SkuMaster, skuDetail and unitDetail. A brief description is below:

SkuMaster table Each record on this table pertains to an OEM-part and includes the demand history at the packager for the most recent 24 months.

UnitDetail table This is a table with the current on-hand and on-order data for each sku (package-component).

The FIRM routines typically run as follows:

FR routine This routine is run once a month (sometimes each week) and generates 12 monthly forecasts for each OEM-part. The SkuMaster table holds the packager history demand data as input and also the output of the 12 months of forecasts.

SkuOpol routine This routine is typically run in tandem after the FR routine. The routine has two input tables: the skuMaster table and the skuDetail table. This routine serves as an interface between all the pending OEM-parts and the package-components (sku). For each part and sku combination, the computations determine the order-point and order-level by sku. The results are placed on the skuDetail table.

Summary

This paper shows how FIRM can be used to control the package-component inventory in a straightforward and economic way. The goals are the following: systematically replenish the package-component inventory, have the right package-component inventory available to meet the due dates on the incoming flow of OEM-parts and identify any excess package-component inventory as a candidate to return to the packager-supplier.