Decision support system for the management of an agile supply chain6151582Abstract A decision support system for managing an agile supply chain including a server side and a client side. The server side includes a decision support system database that interfaces with a model engine that performs analysis of the data to support planning decisions. The server side also includes a server manager that coordinates requests for service and information. The client side includes decision frames that present the various view points available in the system to the users. A frame manager coordinates the requests from the decision support frames to access the needed data and models. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
__________________________________________________________________________
A single consolidated table with redundancy (not in normal form)
Orientation
Customer
Customer
Product
Product
Time Calendar
Date
Time
HeaderID Resolution ID Resolution ID Resolution ID Created Period
Quantity
__________________________________________________________________________
1 C BESTB
P 19PR14C
M 1 1/1/96
8/1/96
10
2 C BESTB P 19PS52C M 1 1/1/96 6/1/96 20
2 C BESTB P 19PS52C M 1 1/1/96 7/1/96 30
2 C BESTB P 19PS52C M 1 1/1/96 8/1/96 75
2 C BESTB P 19PS52C M 1 1/1/96 9/1/96 50
3 C BESTB P 6P4830W M 1 1/1/96 6/1/96 12
3 C BESTB P 6P4830W M 1 1/1/96 7/1/96 40
3 C BESTB P 6P4830W M 1 1/1/96 8/1/96 57
4 C SEARS P 554528 M 1 1/1/96 9/1/96 50
4 C SEARS P 554528 M 1 1/1/96 10/1/96 2
4 C SEARS P 554528 M 1 1/1/96 7/1/96 3
5 C SEARS P 6P4830W M 1 1/1/96 2/1/96 2
6 C SEARS P 6P4830W M 1 1/1/96 5/1/96 74
7 C SEARS P 6P4830W M 1 1/1/96 3/1/96 3
7 C SEARS P 6P4830W M 1 1/1/96 6/1/96 565
7 C SEARS P 6P4830W M 1 1/1/96 4/1/96 500
__________________________________________________________________________
Data Tables The data tables in the DSS Database 12 are preferably specified as follows: Name of the table; Brief description of the data contained in the table; Identifier for the data fields; Type of the data field; and Brief description of the data fields (this includes the choice of values for the data in this field, if applicable). The specifications of the data tables for the manufacturing and equipment repair supply chains can be found in Appendices A and B, respectively. The list of the preferred tables in the DSS Database 12 for these chains is as follows: Aggregate Production Plan Data; Aggregate Production Plan Header; Budget Data; Budget Header; Calendar; Component; Component Accommodation Matrix; Component Requirement Data; Component Requirement Header; Component Supplier; Component Supply Contract; Component Supply Node; CPRD Table; Customer; Customer Group; Customer Group; Definition; Customer Orders; DataField Definition; Demand History Data; Demand History Header; Demand Node; Demand Orientation Data; Demand Orientation Header; Domain; Domain Definition; Feature Choices; Forecast Data; Forecast Header; Freight Rate; Inventory Data; Inventory Header; Inventory Node; Inventory Parameters; Market Data; Market Header; Material Delivery Schedule Data; Material Delivery Schedule Header; Planning BOM; POS Data; POS Header; Product; Product Features; Product Group; Product Group Definition; Production Accommodation Matrix; Production Capacity Data; Production Capacity Header; Production Matrix; Production Node; Production Requirements Data; Production Requirements Header; Promotion Data; Promotion Header; Resource; Resource Group; Resource Group Definition; Sales Requirements Data; Sales Requirements Header; Scenario; Scenario Data; Compatibility; Scenario Definition; Setup Matrix; Supply Chain Network; Supply Order Data; Supply Order Header; Temporary Product List; VMR Contract; VMR Data; and VMR Header. Core Reports The present invention preferably provides core reports that support business decision processes by characterizing the link between the various data elements and processes. They synthesize the data and information used in the decision making processes. Associated with each key business process, we will demonstrate the data flow relationships that are used to construct the various forms and reports. Some of the preferred forms and reports relevant to the DSS 10 are: Sales Plan; Customer-Demand History; Production-Sales-Inventory Plan; Master Production Plan; Production Capacity Plan; Replenishment Schedule; Customer-DC Assignment; and Supply-DC Assignment. Decision Support Frames Overview From a user perspective, a Frame 16 is an integrated decision support environment based on an abstraction of the supply chain designed to address a set of related decision problems within a decision process. A Frame 16 is therefore defined based on the vantage point or view point of the users along a supply chain. This implies that a frame exists if and only if there are users with specific needs in the supply chain. From a system perspective, a Frame 16 is a mechanism that unifies the user dialog and display, the models and analysis routines, and data in a manner that is consistent to support the underlying supply chain abstraction of the user. A summary of the frame concept from both a user and a system perspective is shown in Table 4.
TABLE 4
______________________________________
Frame Concept: User's and System Perspective
User Perspective System Perspective
______________________________________
An environment to address
It is a subsystem that
a collection of related processes user requests in
decision problems. the form of Scenarios.
Always associated with a It consists of a
decision maker or a group consistent set of process
of decision makers. Frame and data models.
exists if and only if
there are decision
makers.
Has a unique perspective It unifies the User
of the underlying supply Interface, Model Engine,
chain based on the and DSS Database elements
responsibility of the that are specific to a
decision makers decision making process.
associated with the
frame.
Enhances the coordination A convenient client-server
of decision making architecture that enables
implicit in the the extension of the DSS
definition of the frame. functionaiity.
Enforced through
organizational
accountability and
responsibilities.
______________________________________
Frame Architecture The high level design of a Decision Support Frame 16 and its interaction with the User Interface 18, the Supply Chain Frame Manager 24, the Model Engine 20, and the Database 12 is illustrated in FIG. 7. A Frame 16/72 is the abstraction of the supply chain from a user's point of view. It essentially contains as its design elements a user dialog 72 and user display 74 and a decision logic 76. The user dialog 73 and the display 74 contain the form and style of the User Interface 18. The decision logic 76 permits the assembly of models and analysis routines and the associated data to address the set of related decision problems. For example, in the case of the PSI Planning Frame 160, the user dialog 72 and display 74 are customized to the specific needs of the PSI planning process, which further determines the design of the User Interface 18 associated with the PSI Planning Frame 160. Users will interact with the PSI Planning Frame 160 through the User Interface 18 by formulating Scenarios 78. Based upon the Scenarios 78, the decision logic 76 in the PSI frame may assemble models and routines from the Model Engine 20 along with the associated data. The decision logic 76 in a frame interacts with the Supply Chain Frame Manager 24 to execute the models and routines. The Supply Chain Frame Manager 24 then provides the performance feedback to the user. Decision Processes in the Manufacturing Supply Chain The decision processes in the is manufacturing supply chain are depicted in FIG. 8. We have identified five decision processes closely associated with the key decision makers and potential users in a supply chain: Overall Supply Chain Management 80, Demand Management 81, PSI (Production-Sales-Inventory) Planning 82, Supply Management 83, and Vendor Managed Replenishment (VMR) 84. Overall Supply Chain Management A supply-chain-wide view and the necessary Management 80 is recognized by all levels of the management as being vital to managing the business. However, decision makers at different levels and points along the supply chain are primarily motivated by their individual roles and responsibilities. The broader a decision maker's responsibilities, the more likely the decision maker is interested in employing decision support capabilities that target the entire supply chain. The user requirements discussed below for decision support are posed from a supply-chain-wide perspective. Given the uncertainty in the medium- to long-term sales forecasts, determine whether or not the enterprise should expand, maintain or reduce its production capacity and/or stocks for the critical components. When changes in business conditions impact one part of the supply chain, assess the potential impact on the other parts of the supply chain. Given different future business scenarios, determine their financial consequences across the supply chain. For the enterprise's supply chain which includes major retailers, determine the appropriate division of responsibilities for all partners in the supply chain. Develop and implement performance incentives that will enhance and encourage supply-chain-wide thinking and decision making in the enterprise. Demand Management Demand Management 81 is the process by which the customers' requirements are characterized with the specification of prevailing uncertainty. The process involves the development and maintenance of medium-term customer (bottom-up) forecasts. These forecasts are initially developed in periodic joint meetings or communications between the decision makers of the enterprise and the customers. Subsequently, these forecasts are input into the enterprise's supply management system to obtain product allocation approval (place-keeping order). As the actual purchase orders arrive, the enterprise attempts to fulfill the requirements to their customers' satisfaction. We have identified the user requirements discuss below for decision support for this process. Synthesize information from different sources in order to manage the demand requirements effectively, e.g., accessing point-of-sales (POS) data and comparing these with shipment history and customer forecasts. For key customers, develop customer-specific sales forecasts based on historical shipment and sell-through data. Link POS data, where available, to the historical promotion information to analyze the real impact of promotion activities on demand, as opposed to relying on the estimates provides by the retailers. PSI Planning PSI Planning 82 is a process to determine a set of feasible sales, production and inventory requirements for medium to long-term capacity and resource planning for the logistics operations. At the beginning of each fiscal year, an initial PSI plan can be developed based on the long-term top-down sales forecast and budget plans. The planning process then becomes a continuous effort to update the existing PSI plan to accommodate the changes in the requirements before and after a series of monthly PSI planning meetings whose participants include decision makers representing all key functional areas at the enterprise. The meetings integrate the inputs from various sources, resolve possible conflicts, and balance the concerns of different functions in order to reconcile, develop and approve a new set of feasible sales, production and inventory requirements. The process represents a focal point for the entire logistics planning process, and interacts and coordinates with all major decision making processes. We have identified the user requirements discussed below for decision support for this process. Generate market trend forecasts by product categories for the enterprise as well as the entire industry. Such forecasts will be based on available shipment history, industry survey data and influential economic indicators. Generate forecasts for new products and managing product transitions. Facilitate development of medium-term top-down and bottom-up sales forecasts for the enterprise. Facilitate development of production plans and the associated requirements plans for critical components. Evaluate the effects and understand the implications of specific changes in the sales or production plans. Conflict resolution mechanisms are needed to adapt and maintain these plans. Identify those products that would be affected by the shortage of certain critical components; one possible approach is to use an implosion tool on the bill of materials. Provide a formal mechanism to determine and re-adjust appropriate inventory levels for various products. Supply Management Supply Management 83 is a process to determine the production (supply) plan to meet the production (supply) requirements generated by the PSI Planning process. The process involves component procurement and factory production planning based on the PSI plans and their changes. At the beginning of the process, the production line capacities are created based on long-term product plans, i.e., planned new product release. The process continuously updates the production (supply) plan based on changes in the production (supply) requirements generated in the PSI process. We have identified the user requirements discussed below for decision support for this process. Determine the feasibility and the economic viability of changes in the production (supply) plan, when changes occur in the PSI plans. This requirement is motivated by trade-offs between the PSI process and the production (supply) planning process. Evaluate possible options to accommodate changes in the production requirements, after the line structure and capacity are determined. Such an analysis is a requirement of the factory planner. Develop an aggregate level representation of the production line capacities so as to help the planners in developing aggregate production plans or checking production capacity. Develop a rough-cut analysis capability to assist the planners in translating the production requirements into critical component requirements, i.e., components featured in the planning bill of materials. Vendor Managed Replenishment (VMR) VMR 84 is a process in which the supplier takes on the responsibility of managing the inventory at the customer site for the products it supplies. This process operates on point-of-sales demand as opposed to demand forecasts provided by the customers. VMR involves formulating the contractual agreements between the enterprise and the retailers as well as determining the operating parameters such as shipment quantities and replenishment frequencies. We have identified the user requirements discussed below for decision support for this process. Develop a strategic analysis tool to determine mutually beneficial VMR contracts based on financial and logistics factors. Develop the replenishment plan based on factors such as sell-through and inventory information provided by the retailer, promotion activities, product availability and transportation cost trade-offs. Decision Processes in the Equipment Repair Supply Chain Overview of the Equipment Repair Supply Chain The equipment repair supply chain 90, as depicted in FIG. 9, includes the operating location 92, i.e., the point-of-use, the repair shop 94, and the component suppliers 96. In an equipment repair supply chain, the demand (or the "requirements") are generated by equipment failures. When equipment fails, the failed module is replaced from the stock at the operating location 92, and the failed module is eventually sent to the repair shop 94 for repair. A module is made up of repair items which in turn are made up of components. At the repair shop 94, the repair is carried out by the repair resources (people and machinery). During the repair process at the repair shop 94, certain repair items and components are replaced. Based on the repair needs, repair items and components will be ordered from the sources of supply by the repair shops. Equipment Operating Location 92: At the equipment operating location 92, personnel may replace only certain repair items of the module, instead of the whole module These replacement repair items may come from the stock or from other failed modules. This process encourages consolidation of failed modules at the operating location. In the consolidation process, the broken repair item of a broken module is replaced by a good repair item from another broken module. This process may be motivated by the structure of the repair cost function and the need for quick repair. In some cases, due to the fixed costs of sending individual modules to the repair shop, modules are batched to a certain level, before they are sent to the repair shop for a complex overhaul. Repair Shop 94: The repair shop 94 is responsible for all the major repairs. The type of repair to perform is driven by the level of good modules at the repair location. When good modules are sent from the repair shop to the operating location, the stock level may drop below the target level, thus triggering a repair request to bring the stock level up to the target level. This target level is determined with the objective of maximizing the equipment availability and minimizing the repair costs. Component and capacity requirements corresponding to a repair request should be feasible with respect to component availability and resource capacity levels at the repair shop. Parallel With the Manufacturing Supply Chain We recognize the operational differences between manufacturing and equipment repair supply chains. However, the equipment repair supply chain has clear parallelism with the manufacturing supply chain where the repair items correspond to products and components correspond to materials. Equipment operating locations are similar to retailers and equipment is like customers. The repair shop is analogous to a production facility. As modules are made up of repair items, modules correspond to product groups. The repair requirements management process is analogous to demand management, and repair supply management to supply management. Similar to the PSI process, there exists a reconciliation process in the equipment repair supply chain to ensure balance between requirements and supply. Application to a National Defense Application For a national defense application, the following nomenclature is used. The equipment located at various operating locations are the aircraft operating at the various bases. The modules correspond to the Line Replaceable Units, or LRUs and the repair items correspond to Shop Replaceable Units (SRUs). The failure of an LRU, caused by the failure of its SRU, renders the aircraft unavailable. The function of the base is to provide immediate support to the aircraft located at that base, with the objective of maximizing availability of aircraft. For that purpose, bases stock good units of replaceable items, called serviceables, so as to be able to replace a failed LRU of an aircraft immediately. A base, usually, is not involved in major repairs. Instead, it implements a consolidation policy (replacing the defective SRU of a newly failed LRU with a good SRU of an already defective LRU), which gives the base the ability to manage the repair requirements of the depot. Managing the repair requirements refers to deciding when and which defective items the base will send to the depot for repair with the objective of maximizing the availability of aircraft located at the base and minimizing total cost of repair (which includes a fixed cost component). A depot is responsible for all the major repairs. The type of repair to perform is driven by the level of good repairable items at the depot. When good repairable items are sent from the depot to the base, the stock level may drop below the target level, thus triggering a repair request to bring the stock level up to the target level. This target level, also called the Consolidated Serviceable Inventory (CSI) level, is determined by the depot with the objective of maximizing its service level and minimizing its repair costs. Component and capacity requirements corresponding to a repair request should be feasible with respect to component availability and resource capacity levels at the depot. Table 5 below presents the analogy and nomenclature between the equipment repair supply chain, and the manufacturing supply chain with examples from defense and commercial environments.
TABLE 5
______________________________________
Analogy and nomenclature between equipment
repair and manufacturing supply chains
Example
Example Commercial Parallel
Equipment Defense Equipment with
Repair Equipment Repair Manufactur
Supply Repair Supply ing Supply
Chain Supply Chain Chain Chain
______________________________________
Equipment Aircraft MRI Machine Customers
Module LRU Cabinet Product
Group
Repair LRU / SRU Circuit Product
Item Boards
Component Bit and IC Component
piece part
______________________________________
Decision Processes in the Equipment Repair Supply Chain The supply chain comprises (see FIG. 9) the following three decision processes: Requirements Management Process 98; Requirements-Supply Reconciliation Planning Process 100; and Supply Management Process 102. Requirements Management Process The Requirements Management Process 98 concentrates on the activities associated with requirements estimation. The objective of this process is to estimate future repair requirements generated by equipment failures. Equipment has several repairable parts and equipment failures are caused by failures of the repairable parts. Hence estimating future requirements refers to the process of estimating failures of the equipment and of the repairable parts that caused the failures. This is done to estimate repair time requirements (determined in Requirements-Supply Reconciliation Planning Process) and equipment availability at equipment locations, both of which depend on the part that has failed. Requirements can be analyzed in two levels: Lower level requirements, called the Raw Requirements, correspond to all repair requirements of the equipment and upper level requirements, called the Consolidated Requirements, correspond to requirements requested from the repair shop, since equipment locations may prefer accumulating their repair requirements and sending them to the repair shop according to certain rules instead of sending them as they occur, or may prefer carrying out minor repairs within the location, with the aim of reducing the fixed and variable costs of repair. In the manufacturing analogy, raw requirements would correspond to Point of Sales (POS) data and consolidated requirements to retailer order data from the production facility. Two different estimation approaches that have been used in this process to estimate consolidated requirements are: Bottom-up Estimation Approach; and Top-down Estimation Approach. The bottom-up estimation approach estimates the raw requirements first and then generates the consolidated requirements from raw requirement estimates. In order to estimate raw requirements, relationships are determined between failure rates and activity schedules of the equipment. For example, the time to failure of an equipment can be a function of the number of hours it has operated and its maintenance schedule. Once the relationships between failure rates and activities are established by regression or time series models, future failure rates can be estimated based on the planned activity schedules of the equipment. Given the estimated raw requirements, the next step is to go to the upper level and estimate consolidated requirements, that is requirements as seen by the repair shop (assuming that repair shop does not have access to raw requirements data). Consolidated requirements depend on what frequency the operating location will send its repair requests to the repair shop. This is analogous to the inventory replenishment policy of a retailer in a manufacturing system. In deciding on the type and parameters of the inventory replenishment policy, the facility will use several conflicting performance measures such as minimizing total repair cost and maximizing availability of the equipment. Thus, given the inventory replenishment policy of the facility and estimates of its raw requirements, its consolidated requirements can be estimated. The top-down estimation approach makes use of historical data to estimate consolidated requirements. Statistical forecasting techniques can be used to support this process. The two estimates obtained by bottom-up and top-down approaches are compared, analyzed and reconciled to generate final estimates for consolidated repair requirements. The output of this process is the estimated consolidated requirements for an equipment operating location. Requirements-Supply Reconciliation Planning Process The second process is the Requirements-Supply Reconciliation Planning process 100 that aims at developing an integrated repair plan for the repair shop through a reconciliation process. First, the type and parameters of the repair policy of the repair shop are to be determined. Aggregate repair requirements are generated based on the repair policy of the repair shop and estimated consolidated requirements for all facilities. The next step is to generate an aggregate repair plan based on repair time estimates for each repairable part and the aggregate repair requirements. Feasibility of the aggregate repair plan is checked with respect to resource constraints which are repair resource capacities and key component availability. If the aggregate repair plan is not feasible with respect to resource constraints, then causes for infeasibility are identified and the infeasibility is removed by either changing the level of the resource constraints or moving aggregate requirements forward or backward in time. This procedure is repeated until an aggregate repair plan that is feasible with respect to resource constraints is attained. The supply management 102 (see FIG. 9) is a process to determine the repair plan considering repair people, test equipment and key components. It starts by the translation of the aggregate repair plan into a detailed plan concerning repair resources (repair persons and test equipment), and component requirements. Based on these requirements and the capacity constraints for the repair resources, repair personnel and key components, a detailed repair plan is developed using an optimized based modeling approach. The detailed repair plan is used to generate the key component delivery schedule to be transmitted to the component suppliers. In addition, the supply management process 102 is also concerned with the development of appropriate procurement policies for key components in terms of identifying the policies, and deriving the corresponding policy parameters. Basic Frames The basic Frames 16 of the present invention collectively provide coverage for the overall supply chain. The specific instances of these Frames 16 in a particular DSS 10 implementation depend largely on the constituent supply chain, the underlying business processes, and the organizational structure. Table 6 below lists the Decision Support Frames 16 in the context of manufacturing and equipment repair supply chains.
TABLE 6
______________________________________
Decision Support Frames in the Context
of Manufacturing and Equipment Repair Supply Chains
Manufacturing Supply
Equipment Repair Supply
Chain Chain
______________________________________
Demand Management Requirements Management
PSI Planning Requirements-Supply
Reconciliation
Supply Management Supply Management
Vendor Managed
Replenishment
Finished Goods
Distribution Network
Design
______________________________________
Specification of the Basic Frames To specify each basic Frame 16, we use influence diagrams to map the modules in the Model Engine 20 and the Data Spaces to the frame. We use process flow diagrams to outline the high level design of the logical relationship among the key data tables, the modules and the basic Frames 16. We also discuss how to support key functional requirements in each frame. To complete the specification of the basic Frames 16, we use data flow diagrams to map the data tables to the core reports in each frame. The legend for the process and the data flow diagrams which will be discussed herein after is shown in FIG. 10. Demand (Requirements) Management Frame The Demand Management Frame 130 supports the demand management decision process described here. Manufacturing Supply Chain Module and Data Space Association FIG. 11 shows the participating modules and the associated data spaces for this frame. The Demand Management Frame 130 requires the participation of two modules: the Sales Forecasting and Planning (SFP) Module 132 and the Market Data Analysis (MDA) module 134. The SFP Module 132 in the Demand Management Frame 130 essentially operates in the D data space, i.e., it transforms data within the conceptual demand data domain. The MDA Module 134 in the Demand Management Frame 130 operates in the I and the D data spaces and relates the I data space to the D data space, i.e., it may transform data within the individual D data space as well as transform data from the I data space to the D data space. The data space representation of the Demand Management Frame 130 is the union of the data space representations of each participating module, and the interactions among participating modules. The high level representation of FIG. 11 can be complemented by the process flow diagram for this frame, described next, that will detail the connections between the constituent modules and the associated data tables. Process Flow The process flow diagram for the Demand Management Frame 130 is shown in FIG. 12. The modules, data tables, and the principal activities within the scope of this frame are clearly marked by the grooved double-lined border. Only the data tables that are updated by the frame are considered to be within the scope of the frame 130. Other frames, activities and data tables that are related are also shown for completeness. The Order Fulfillment 149, that is out-of-scope of the Demand Management Frame 130 but related to it, is shown separately in FIG. 13 for purposes of clarity. This representation of interaction between Frames 16 is consistent with the interaction between decision processes shown in FIG. 8. The Demand Management Frame 130 supports the functional requirements described below. Demand Characterization--Demand data from various sources such as Demand History Data 136, POS Data 138, Market Data 140, and Promotion Data 142 as well as top-down and bottom-up Forecast Data 146 obtained by buyers and account managers will be consolidated and synthesized by the MDA Module 134 and the SFP Module 132. Bottom-up Demand Forecasting--Demand Review 144 consolidates demand information received directly from the customer along with the input from the MDA Module 134 and then develops Demand Orientation Data 148. The SFP Module 132 will then use Demand Orientation Data 148 as well as other inputs, e.g. Promotion 142 and POS 138 Data, to develop the customer-centric bottom-up forecasts in Forecast Data 146. Top-down Forecasting--The SFP Module 132 will use market and industry-wide trend analysis performed by the MDA Module 134 along with the enterprise's shipment history to generate the product-centric top-down forecasts in Forecast Data 146. Sales Promotion Analysis--The MDA Module 134 reviews the demand history from POS Data 138 and Demand History Data 136 along with the customer promotion information from Promotion Data 142 to analyze the impact of promotions on sales. The results of such an analysis are then used to help adjust sales forecasts to account for promotions. Forecast Performance Evaluation--Using Demand Orientation Data 146, Demand History Data 136 and Promotion Data 142, the SFP 132 and MDA Module 134 can evaluate the quality of enterprise's forecasts and the customer projections. Data Flow The data flow diagram for the Demand Management Frame 130 is shown in FIG. 14. The Demand Management Frame 130 generates two of the core reports listed earlier, namely, the Sales Plan 152 and the Customer-Demand History 154. For each core report, the associated data tables are shown. The dashed line indicates the influence of an out-of-scope (with respect to the Demand Management Frame 130) data table in the development of the report. For example, the Customer Orders data table 150 is out-of-scope of the Demand Management Frame 130 but influences the Customer-Demand History report 152. Demand Management is the process in which the user determines future requirements based on past requirement history and general information related to the supply chain. In the context of the manufacturing environment Demand Management supports the analysis of past demand and of market trends as well as the development of future forecasts. For the repair environment the term Requirement Management is used in place of Demand Management. Requirement Management is the process where future requirements are estimated based on an analysis of each equipment's activity and on the projection of past requirement history. In the manufacturing context, Demand Management regroups the set of processes by which the user analyzes Market Data 140 and past demand history for the purpose of estimating future demand requirements. The outputs of Demand Management include the analysis of past history, future forecasts, the analysis of special activities such as sales promotions, and the analysis of forecast errors. Two critical outputs of Demand Management are two different medium term forecasts corresponding to two different views on the dynamics of the processes that generate future requirements: the customer centric forecast--generated at the product level for each customer it incorporates the estimations of future demand provided by each customer (Bottom-up Forecast); and the product centric forecast--generated at the product level, it incorporates the impact of market and industry-wide trends on future demand for each product group (Top-down Forecast). These two types of forecast are generated using: Historical projection of past demand; Future orders information; Analysis of the dynamics and characteristics of the overall market and main competitors; and Analysis of the impact of future special commercial activities such as sales promotions. These analyses and projections are grouped in five functional requirements that are detailed in the rest of this section: Demand Characterization, Bottom-up Demand Forecasting, Top-down Demand Forecasting, Sales Promotion Analysis, and Forecast Performance Evaluation. Other frames such as production, sales and inventory (PSI) or vendor managed replenishment (VMR) may directly or indirectly use the output of Demand Management. Demand Characterization The objective of Demand Characterization is to provide the user with an environment where (s)he can access, analyze and synthesize demand data from different sources. These data include: Sales History data (that include POS and shipment data), Inventory data (relative to the inventory position of its product at the customer's stocking points), and Market Data 140. Market Data 140 correspond to various quantitative information, usually provided by external entities such as Nielsen, that relates to the sales for the type of product considered in the entire market. Acquire, Display, Edit Data Data Acquisition consists of selecting a Data Domain (specific pairs of customer and product), and choosing the type of data to be displayed (POS, demand history, inventory, Market Data 140). Data can be edited and modified and saved along with results of analysis in a scenario. Analyze & Synthesize Data Sales History and Customer Inventory Data This involves the operations discussed below. Compute, display (tables and graphs), characterize and analyze sales history per product/product group or customer/customer group (see the MDA Module specification discussion for details of models and formulas): Volatility of demand, Lumpiness of demand, Trends in demand history, Demand pattern changes, and Seasonality. Compute, display (tables and graphs) and analyze sales history statistics for different levels of aggregation: This year vs. last year, Actual sales vs. budget, and Year to date vs. balance of Year. Compute, display (tables and graphs), and analyze trend in Demand Product Mix by product group. Pareto analysis of sales (or inventory) to identify ABC classification for products (see MDA Module specification for details of formulas). Compute and analyze correlation between the demand for different product groups. Compute, display (tables and graphs), and analyze new products and model change-over profiles. Compute, display (tables and graphs), and analyze inventory profile per customer. Compute, display (tables and graphs), and analyze trade inventory by comparing POS and shipment data. Market Data This operation involves the operations discussed below. Display (tables and graphs) Market Data 140 (volume, value, market share) by product group, region, or customer group (Nielsen, EIA, etc.). Compute, display (tables and graphs) and analyze Market Data 140 statistics for different levels of aggregation: This year vs. last year, Trend, Actual statistics vs. budget assumption, and Seasonality. Pareto analysis of competitors (value and volume). Create price information: list of competitor products per price range. Bottom-Up Demand Forecasting The objective of the Bottom-up forecasting is to develop a customer specific sales forecast based on historical shipment to the customer, POS information at the customer location, and the customer's own forecast regarding its future orders. Acquire, Display, Edit Data Data Acquisition consists of selecting a data Domain (specific pairs of customer and product), and choosing the type of data to be displayed: shipment or POS (when available). Forecasts generated in the Bottom-up forecasting frame can be saved back to the DSS Database 12 or alternatively saved as scenario. Bottom-Up (BU) Forecast Generation This operation involves the operations discussed below. Input and maintain customer orders: Forward orders, and Orientation orders. Choose model for statistical forecast. Generate and display (tables and graphs) statistical forecast at different level of aggregation (POS or Shipment data): Customer group, Individual customers for all products, and Individual customers for each product. Support integration in BU forecast of expert knowledge for optimistic/pessimistic forecast. Formulate disaggregation logic of BU Forecast at customer level onto products. Incorporate impact of future promotions for customer specific promotions. Compute, display and edit seasonality factors. Review actual seasonality against planned and "company" seasonality. Disaggregate yearly forecasts onto each period using seasonality factors at different levels of aggregation (POS or Shipment data): Customer group, Individual customers for all products, and Individual customers for each product. Compute and display (tables and graphs) sales and forecast statistics: Moving average, Year to date/balance of year, This year vs. last year, and Actual/forecast vs. Budget. Support comparison of POS and Shipment data for analysis of change in trade inventory profile. Invoke forecast accuracy estimation routine. Top-Down Forecasting The objective of the Top-down forecasting is to develop a product centric sales forecast based on historical demand data and industry analysis that accounts for market-wide trends. Acquire, Display, Edit Data The data Acquisition consists of selecting a data Domain (specific pairs of customer and product), and choosing the type of data to be displayed: shipment or POS (when available). Forecasts generated in the Top-down forecasting frame can be saved back to the DSS Database 12 or alternatively saved as a scenario. Top-Down (TD) Forecast Generation This operation involves the operations discussed below. Choose model for statistical forecast. Generate and display (tables and graphs) statistical forecast at different level of aggregation (POS and Shipment data): market level, product group level, and product line level. Incorporate industry trend analysis developed in Demand Characterization in TD forecast. Formulate disaggregation logic of TD Forecast at product level onto customers. Incorporate impact of future product specific promotions. Compute and display (tables and graphs) sales and forecast statistics: Moving average, Year to date/balance of year, This year vs. last year, and Actual/forecast vs. budget. Compute, display and edit seasonality factors. Review actual seasonality against planned and "company" seasonality. Disaggregate yearly forecasts onto each period using seasonality factors at different levels of aggregation (POS or Shipment data): market level, product group level, and product line level. Support forecasting of model change over, and introduction of new products. Invoke forecast accuracy estimation routine. Sales Promotion Analysis The objective of Sales Promotion Analysis is to analyze the impact of promotional activities. It entails maintaining the promotion calendar, estimating the impact of future promotions and assessing the effect on sales of past promotional activities. The promotion calendar is a table in which the various characteristics of past and future promotions are recorded. The knowledge and insights gained in sales promotion analysis are used in adjusting bottom-up and top-down sales forecasts. The functional features associated with Sales Promotion Analysis are given below. Maintain Promotion Calendar and add new promotions: Time period of promotion. Type of promotion (defined by who initiates the promotion: firm, retailer, competitor), and Class of promotion (defined by the nature of the promotional activity). Intensity of promotion: Search and sort promotion calendar, and Analyze Past Promotions. Display sales data along with information of promotions under consideration. Establish profile for the impact of the sales promotions. Analyze promotion(s) effect through regression or time series models. Partition sales: Display actual sales attributable to normal sales, seasonal effect and promotion effect. Plan Future Promotions. Add promotion in promotion calendar--specify type, class, intensity and time period. Estimate impact of future promotion based on the impact of similar past promotions. Forecast Performance Evaluation The objective of Forecast Performance Evaluation is to assess the accuracy of past sales forecasts. Forecast accuracy is an important measure for several purposes: It helps the user to refine the forecasting process by providing feedback on the ability of different models and approaches to forecast future demand; It provides a measure of demand variability that is used to assess necessary safety stock; and It guides attention to those products and customers for which demand is difficult to forecast and that require special attention. Two types of forecast performance evaluations are considered: forecast accuracy of one particular version of the forecast, and average accuracy of n periods ahead forecast. The first forecast performance type provides point estimations of forecast accuracy, while the second one is an average estimation of the accuracy as a function of the number of period in advance a forecast is produced. The functional features associated with Forecast Performance Evaluation are given below. Select data domain. Compute and display Forecast errors for: Bottom up forecast, Top down forecast, and Sales plan (invoked from PSI). Maintain Accuracy Matrix for each type of forecast (table of the forecast accuracy n periods ahead). Generate exception report based on level of forecast error for different level of aggregation. Equipment Repair Supply Chain In the context of the Equipment Repair Supply Chain the term "Requirements Management" is used in place of "Demand Management" to indicate that equipment generates "repair requirements" when it breaks down. Requirements Management is the process of estimating the future requirements of reparable items at the equipment location. This process can be divided into two main sub-processes: Evaluation of the raw requirements for each equipment; and Estimation of the consolidated requirements at the level of each location (several pieces of equipment can be located at the same location). These two approaches can be used to estimate future consolidated requirements. Bottom-up method: This approach uses a combination of two models: (1) the first model estimates the raw requirements of an equipment by modeling its failure rate as a function of the equipment's activity (or usage) and (2) the second model estimates the consolidated requirement based on the raw requirements and the consolidation policy. Top down method: This approach is based on the projection of historical data for the consolidated demand. To support the two different approaches the functional requirements detailed below have been defined. Activity Tracking for Raw Requirements Estimation This involves the operations discussed below. Select and Display Activity Data. Maintain Future Activity Data: Planned Equipment upgrade/maintenance schedules; and Planned Equipment usage schedules. Analyze Past Activities. Review activities: Display historical raw requirements data along with activity data. Assess impact of past activities using regression or time series models. Per type of equipment. Per type of activity. Relate future raw requirements to planned activities. Use models of past activities to project the effect of future activities. Consolidated Requirements Estimation Based on Raw Requirements (Bottom-Up) This operation involves the operations discussed below. Select and Display Consolidated Requirement data. Formulate, and refine consolidation policy (see SFP Module for explanation regarding consolidation policies). Evaluate different consolidation policies based on past raw requirements. Estimate future consolidated requirements based on chosen policy. Consolidated Requirements Estimation Based on Historical Data (Top-Down) This involves the operations discussed below. Select and Display Consolidated Requirement data. Choose model for statistical forecast of future usage per repair item/repair item group. Kalman Filter based algorithm for requirements estimation (considered appropriate for forecasting equipment failures). Other statistical forecasting techniques. Generate and display (tables and graphs) statistical forecast at different level of aggregation: Repair item group, Individual Repair item for all equipment, and Individual Repair item for each equipment. Compute and display statistics (tables and graphs) for actual and estimated consolidated requirements: Moving average, Year to date/balance of year, This year vs. last year, and Actual/forecast vs. Budget. Develop disaggregation logic of consolidated requirements estimation Forecast at repair item group onto individual Repair item. Users can override algorithm based estimates. Requirements Reconciliation and Requirements Plan Generation This operation involves the operations discussed below. Compare and analyze top-down and bottom-up requirements numerically and visually. Reconcile the top-down and bottom-up requirements to generate the requirements plan. Use weighted average models. Incorporate user's input and override. Requirements Estimation Performance Evaluation Store top-down, bottom-up and reconciled requirements estimates. Compute and display Estimation errors for: Bottom up requirement estimation, Top down requirement estimation, and Reconciled requirement estimation. Maintain Accuracy Matrix for each type of requirement estimation (table of the accuracy n periods ahead). Generate exception report based on level of estimation accuracy for different level of aggregation. Production-Sales-Inventory Planning (Requirements-Supply Reconciliation) Frame The PSI Planning Frame 160 supports the PSI planning decision process described here. Module and Data Space Association FIG. 15 shows the participating modules and the associated data spaces for this frame. The PSI Planning Frame 160 requires the participation of three modules: the Sales Forecasting and Planning (SFP) Module 132, the Aggregate Production Planning (APP) Module 162, and the Finished Goods Inventory Management (FGIM) Module 164. The PSI Planning Frame 160 as a whole involves S, I, and D data spaces with iterative data transformations among each pair. Process Flow The process flow diagram for the PSI Planning Frame 160 is shown in FIG. 16. The PSI Planning Frame 160 supports the following functional requirements identified for the PSI planning decision process: Forecast Reconciliation The Demand Management Frame 130 supplies the Forecast Data 146 (bottom-up and top-down forecasts). The PSI Reconciliation Activity 170 in concert with the SFP Module 132 revises the top-down forecasts and reconciles the bottom-up and top-down forecasts. This is an iterative process which is shown as the "S" loop (in the top right quadrant) in the process flow diagram. If any changes to the bottom-up forecasts are warranted, the PSI Planning Frame 160 interacts with the Demand Management Frame 130 to make the necessary changes. Inventory Planning The PSI Reconciliation activity 170 in concert with the FGIM Module 164 determines the inventory requirements in an iterative fashion. This is shown as the "I" loop (in the top left quadrant) in the process flow diagram. The inventory requirements are written to Inventory Data 182. The FGIM Module 164 as part of the PSI Planning Frame 160 also formulates the finished goods inventory policies; the policy parameters are written to Inventory Parameters 172. Supply Requirement Planning The PSI Reconciliation Activity 170 in concert with the APP Module 160 determines the production requirements that are consistent with the sales plan and the inventory requirements in an iterative fashion. This is shown as the "P" loop (in the bottom right quadrant) in the process flow diagram. The production requirements are written to Production Requirements Data 174. The APP Module 160 as part of the PSI Planning Frame 160 also checks aggregate production capacity and key component availability using Production Capacity Data 180 and Inventory Data 182 (component availability). Production-Sales-Inventory-Plan Coordination The PSI Reconciliation Activity 170 interacts with the APP Module 160, the SFP Module 132, and the FGIM Module 164 to coordinate the integrated production-sales-inventory planning. This involves the evaluation of various plan options, checking the consistency of the constituent plans and resolving conflicts, if needed. Data Flow The data flow diagram for the PSI Planning Frame 160 is shown in FIG. 17. The PSI Planning Frame 160 generates the Production-Sales-Inventory Plan report 190 listed earlier. The Production-Sales-Inventory (PSI) Planning is a process to reconcile demand and supply requirements in a supply chain. In the manufacturing environment, the PSI Planning Frame 160 helps to reconcile production, sales and inventory requirement discrepancies. In the repair environment, the requirements-supply reconciliation helps to reconcile requirements and supply. Manufacturing Supply Chain The PSI Planning Frame 160 supports the process that develops an integrated production-sales-inventory plan for a selected product group. The objective is to ensure that the resulting PSI plan 190 meets customer requirements and satisfies supply capability constraints and the inventory objective of the company. The current PSI plan 190 is displayed together with a temporary PSI plan 190. The temporary PSI plan 190 can be imported from various data sources (including data series from Scenarios 78). The user can then analyze and modify the temporary PSI plan 190 with easy reference to the current PSI plan 190. The user can replace the current PSI plan 190 by the temporary one once the latter has been improved to satisfaction. The PSI planning process requires the support of three modules: the Sales Forecasting and Planning (SFP) Module 132, the Aggregate Production Planning (APP) Module 162 and the Finished Goods Inventory Management (FGIM) Module 164. Forecast Reconciliation The Demand Management Frame 130 supplies the Forecast Data 146 (bottom-up and top-down forecasts) and an indication of the methods used to generate them. The user can use the same methods to generate new forecasts and/or compare the forecasts generated by different methods. The user analyzes and reconciles these forecasts to generate an appropriate set of sales requirements. The PSI Reconciliation 170, with the support of the SFP Module 132, revises forecasts and reconciles top-down and bottom-up forecasts. Revise Forecasts The forecast revision process acquires, displays, analyzes and edits the bottom-up or top-down forecast. The user first acquires forecasts generated using different methods from the Demand Management Frame 130. After analyzing these forecasts and comparing the results, the user then selects the most appropriate one to be used. The following features are identified for this process: Acquire and display forecasts; Check forecast errors; Compute and display related statistics of sales; and Select forecasts. Individual descriptions of these four features are as follows. Acquire and Display Forecasts This feature consists of the following four steps: Choose product group: The user specifies the product group of interest. Choose aggregation level: The user specifies the aggregation level (e.g. month, year) for data display. Import forecasts: The DSS 10 acquires the bottom-up and top-down forecasts generated in Demand Management Frame 130 for the selected product group from the DSS Database 12. Display forecasts: The DSS 10 aggregates/disaggregates as appropriate the forecasts to display at the chosen aggregation level. Check Forecast Errors The forecast error checking feature supported by the SFP Module 132 computes and displays various n-period-ahead historical errors of the bottom-up and top-down forecast. Compute and Display Related Statistics of Sales The sales statistics computation feature supported by the SFP Module 132 computes: mean and variance over a selected time interval, moving average, trend, and/or seasonality factors of any chosen sales line and display result in several forms (graphical, tabular or both). Select Forecasts The forecast selection feature interacts with the Demand Management Frame 130 to check bottom-up forecasts from various sources and the result of various top-down forecast methods (e.g. moving average, regression, combinations, etc.) The user then chooses the most appropriate set of bottom-up and top-down forecasts based on their accuracy, statistics and consistence with each other. Reconcile Top-Down and Bottom-Up Forecasts The process of top-down and bottom-up reconciliation checks the discrepancy between the two forecasts and if necessary, resolves the conflicts between the two forecasts to generate a more desirable sales forecast. The following features are provided to support this process: Compute the difference between top-down and bottom-up forecasts; Generate weighted average of top-down and bottom-up forecasts; and Manually overwrite temporary sales (S') line (see the screens discussed later herein). Individual descriptions of these three features are as follows. Compute the difference between top-down and bottom-up forecasts. The difference between top-down and bottom-up forecasts is computed and displayed to show the discrepancy between the two forecasts. Generate weighted average of top-down and bottom-up forecasts. The conflicts between the top-down and bottom-up forecasts can be resolved by using a weighted average of them to generate a new temporary sales forecast in the S' line. Manually Overwrite Temporary Sales (S') Line The user manually overwrites the forecast on the S' line to adjust the sales forecast to reflect various considerations of influential factors. For example, adjust sales forecasts to account for unrecorded or anticipated upcoming market changes. Inventory Planning The process of Inventory Planning supported by the FGIM Module 164 and the Demand Management Frame 130 determines the finish goods inventory requirements. In inventory planning, the user first selects a product group. To help the user to select an appropriate inventory policy, the DSS 10 computes and displays various sales measures which characterize the sales pattern of the chosen product group. For example, a Min-Max policy might be appropriate for a product group facing steady demand. The DSS 10 then, based on the inventory policy selected by the user and the managerial sales and service targets, determines the policy parameters and inventory level requirements. The user can then modify the policy parameters and inventory level requirements to satisfy various managerial requirements and production resources limitations. The following two features are identified for this functional requirement: Formulate finished goods inventory policies; and Determine finished goods inventory requirements. Formulate Finished Goods Inventory Policies The formulation of finished goods inventory policies involves the selection of inventory policies for chosen product groups and specifying the corresponding policy parameters. It is broken down into the following features: Choose inventory policies for product groups; Choose policy parameters; and Compute estimated inventory statistics. Individual descriptions of these three features are as follows. Choose Inventory Policies for Product Groups In this feature, the user select inventory policies for product groups based on the patterns of sales the product groups are facing. It involves the following three steps: Choose product group: The user specifies the product group(s) of interest; Acquire the following sales measures from the Demand Management Frame 130: Usage rate--fast, medium or slow moving, Lumpiness--sparseness of significant demands, and Volatility--coefficient of variation; and Select inventory policy: The user chooses among the following an inventory policy for the chosen product group(s) based on the sales information acquired. For single product group with non-lumpy demands: User-specified base-stock policy, Periodic review cost optimization policy, and Period review model with service level constraints. For related multiple product groups (e.g. groups sharing the same production resources.) with non-lumpy demands: Leveled Policy, Synchronized Policy, and Optimal Policy. For single product group with lumpy demand: Maximum n-Period Coverage Policy. Choose Policy Parameters The FGIM Module 164 based on the service level constraints and managerial objective (e.g. minimize inventory carrying cost with a stock out probability of at most 5%) determines the policy parameters to be used for the inventory policy chosen by the user. The user can then observe the results of the estimated inventory statistics and adjust the policy parameters as appropriate. Compute Estimated Inventory Statistics The estimated inventory statistics calculation feature supported by the FGIM Module 164 computes and displays the following inventory related measurements: average inventory level (as weeks of sales); expected stock-out probability; service level (fill rate); inventory carrying cost; and total cost (including production, inventory holding, stock out penalty and transportation costs) for the chosen inventory policy and policy parameters. Determine Finished Goods Inventory Requirements The FGIM Module 164 based on the inventory policy and policy parameters determines the finished goods inventory requirements for the product groups. The user can then modifies the inventory level requirements as appropriate. The following features are identified for determining the finished goods inventory requirements: Compute and display inventory level at chosen aggregation level; Manually override inventory levels; and Compute and display inventory level at chosen aggregation level. The PSI Planning Frame 160 supported by the FGIM Module 164 computes the inventory levels based on the chosen inventory policies and parameters. The result will be displayed in the temporary inventory (I') line. If the computation is done at a lower aggregation level than the chosen one for display, the corresponding appropriate aggregation will be done before display. Manually Override Inventory Levels The user can manually overwrite inventory levels to reflect various managerial concerns. For example, the unavailability of production resources at certain periods requires the decrease in corresponding inventory levels or the suggested inventory level exceeds the given management target. Supply Requirement Planning The supply requirement planning feature supported by the APP Module 160 help determines the production requirements that are consistent with the sales plan and the inventory requirements. It also checks the feasibility of the production requirements with respect to production capacity and key component availability. In case of infeasibility, the feature will provide information about the cause of corresponding infeasibility to the user. The user can then modifies sales requirements, increases available resources (production capacity or key component availability) and/or prioritizes the sales requirements and restricts attention to satisfy a reduced set of high priority sales requirements only in order to achieve feasibility. Determine Production Requirements to Sustain Sales The process of determining production requirements to sustain sales consists of the following two features: Generate production requirements; and Manually overwrite the production requirements. Individual descriptions of these two features are as follows. Generate Production Requirements The production requirements generation feature supported by the APP Module 160 determines the production requirements based on sales and inventory requirements. There inventory requirements may take two different forms: Inventory levels, or Safety stocks. In case of inventory level requirements, the production requirements are generated using the inventory balance formula discussed herein. In case of safety stock inventory requirements, the user can choose one of the following objectives to determine the production requirements: Minimize the maximum production capacity utilization; Minimize the maximum inventory level; Minimize the total inventory level; and Minimize the total inventory cost (inventory holding and backlog penalty costs required). The production requirements generated are displayed in the temporary production (P') line. If result of sanity check is at a lower aggregation level than the one chosen for display, aggregation will be done before display. Manually Overwrite the Production Requirements The production requirements are modified to reflect various considerations. For example, insufficient production resources during certain periods. Check Aggregate Production Capacity & Key Component Availability In the process of checking the feasibility of sales, inventory and production requirements against the availability of production capacity and key components, the following features are identified: Define key components; Check sanity of a given set of sales requirements (in S' line) and safety stock constraints; Check feasibility of production requirements (in P' line); and Update and display production capacity load and key component availability. Individual descriptions of these four features are as follows. Define key components. Each user defines a list of key components, which is recorded and can be modified whenever necessary. The list of all components which are sorted according to their availability/usage ratio is displayed to help the user to define or modify the list of key components. Check sanity of a given set of sales requirements (in S' line) and safety stock (in I' line) constraints The process of sanity check utilizes the capacity checking model in the APP Module 160 to help determine the production requirements for the given set of the sales requirements and safety stock constraints. Furthermore, the user can scope the capacity checking model appropriately through modification of: Location(s), Products or product groups, Time horizon, Production lines, and Key components. If the results of the capacity model are infeasible, critical under-capacitated production resources and key components are suggested to the user for further modifications. Check feasibility of production requirements (in P' line) This process checks sanity of a given set of production requirements against the production capacity and key component availability. This is also supported by the capacity checking model in the APP Module 160. Similar to the previous sanity check described above, the user chooses the appropriate scope of the capacity checking model and if it turns out to be infeasible, critical under-capacitated production resources and key components are suggested to the user for further modification. Update and display production capacity load and key component availability After a few iterations of the sanity checks and capacity requirement adjustment, the user can reach a feasible set of production requirements. The remaining available production capacity and key components are updated and can be displayed if requested. The user can then accept or reject new production requirements based on the availability of production capacity and key components. Production-Sales-Inventory Plan Coordination The coordination of the production-sales-inventory plan ensures consistency among the production, sales and inventory plans and helps determine a feasible and appropriate PSI plan 190. Check and ensure consistency in PSI plan The user can utilize this feature in either: the independent mode or the consistent mode. In the former mode, the user can edit the production, sales and inventory requirements separately by disregarding any consistency requirement. In the latter mode, the DSS 10 always ensures the consistency of the production, sales and inventory requirements. In the consistent mode, the following features are identified: Modify the plan according to the user defined sequence; Maintain the consistency in other lines due to the change of one line; Update the production (P), sales (S) and inventory (I) lines (see display figures discussed herein) by their corresponding temporary lines; Maintain consistency at different aggregation level (for either the consistent or independent modes only). Individual descriptions of these features are as follows. Modify the plan according to the user defined sequence When the user first switches to the consistent mode, two of the temporary production, sales and inventory lines have to be selected to generate the third line using the inventory balance formula discussed herein. Maintain the consistency in other lines due to the change of one line Whenever a temporary production, sales or inventory line is overwritten, it will be modified together with one of the remaining two lines (pre-selected and can be re-selected anytime by the user) to maintain consistency. Update the production (P), sales (S) and inventory (I) lines by their corresponding temporary lines The user can replace the set of P, S and I display lines (see display discussion herein) by a set of consistent P', S' and I' lines. The P, S and I lines can always be saved as a scenario. Only user with the appropriate system privilege can save the P, S and I lines to the DSS Database 12 permanently. Maintain consistency at different aggregation level The DSS 10 can display data at any resolution higher than the primary data resolution level. Whenever display at a higher resolution is modified, disaggregation will be done to maintain consistency. The DSS 10 computes a set of default disaggregation logic based on existing lowest resolution data. The user can overwrite the disaggregation logic whenever appropriate. Evaluate PSI plan options The PSI plan options evaluation feature computes and displays the performance metrics for various versions of the PSI plan 190 for the user to compare and choose a desirable one. The following two features are identified to support this feature: Compute relevant performance metrics; and Compare different plans. Individual descriptions of these two features are as follows. Compute relevant performance metrics The following performance metrics are computed using the routines specified in the SFP 132, FGIM 164 and APP Module 160 to assist the user to select a more desirable version of the PSI plan 190: Total and breakdown of costs, Average inventory level, Average expected stock-outs, Expected Throughput Time, and Expected Service level. Compare different plans Different PSI plans 190 over the same or different time periods together with their corresponding performance metrics are displayed side by side for comparison purposes. Repair Environment In the Repair Environment the term "Requirements-Supply Reconciliation" is used in place of Production-Sales-Inventory planning. This reflects the fact that there is no production nor sales in a repair environment but "repair requirements" and "repair supply" in the form of repair workstation capacity and component availability. "Requirements-Supply Reconciliation" Planning is a reconciliation process that develops an integrated and feasible plan. The Requirements-Supply Reconciliation comprises of two main processes: Estimation of the aggregate repair requirements based on the inventory position of serviceable parts at the repair location and the target level for this inventory; and Feasibility assessment for the aggregate repair requirements under resource capacity (skills and workstations) and component availability constraints. To support these processes the following functional requirements have been defined. Evaluate and propose Consolidated Serviceable Inventory (CSI) Levels based on past usage and future usage requirements. The following operations are performed: Refine variability and lumpiness estimates of usage; Refine repair lead time estimates; and Propose target CSI levels. Determine Aggregate Repair Requirements This includes using target CSI levels, and current inventory positions to determine aggregate repair requirements. Generate Aggregate Repair Plan This includes the following: Verify repair resource capacities to satisfy aggregate repair requirements based on; repair personnel skill sets; workstations features; Verify key component availability to satisfy aggregate repair requirements; and Generate aggregate repair plan under capacity and component constraints. Supply Management The Supply Management Frame 200 supports the Supply Management decision process. Module and Data Space Association FIG. 18 shows the participating modules and the associated data spaces for this Frame 200. Process Flow The process flow diagram for the supply planning frame 200 is shown in FIG. 19. The Supply Management Frame 200 supports the following functional requirements identified for the Supply Management decision process: Aggregate Production Planning The APP Module 160 works closely with the FGIM Module 164 and uses Inventory Data 182 and the Production Capacity Data 180 to evaluate production and inventory trade-offs. The APP Module 160 also uses the Production Requirements Data 174 from the PSI Planning Frame 160 to generate aggregate production plans. These are written to the Aggregate Production Plan Data 202. Dynamic Replanning The aggregate production plan is often modified by the APP Module 160 to reflect either changing production requirements provided by the PSI Planning Frame 160 through the Production Requirements Data 174 or changing component availability from the Material Planning activity 210 through Material Delivery Schedule 212. Capacity Planning The APP Module 160 utilizes long-term Production Capacity Data 180 from the Product Planning activity 214, the production parameters such as process times from Production Matrix 216, and the planning bill-of-material for the product from Planning BOM 218 to determine the production capacity requirements. In so doing, the APP Module 160 may evaluate a number of production capacity options such as various production line structures and allocation of resources. The capacity plan is written to Production Capacity Data 180. Component Procurement Policy Development The Component Procurement Policy Development (CPPD) Module 230 reviews the long-term component requirements in Component Requirement Data 232 and other relevant component supply information to formulate component procurement policies. The component procurement policy parameters are then written to Component Supply Contract 234. Data Flow The data flow diagrams for the Supply Management Frame 200 are shown in FIG. 20 and FIG. 21. The Supply Management Frame 200 generates the core report previously discussed, namely, the Master Production Plan 240 and the Production Capacity Plan 242. Vendor Managed Replenishment Frame The Vendor Managed Replenishment (VMR) Frame 250 supports the VMR decision process. Module and Data Space Association The Data Space associations for Frame 250 are illustrated in FIG. 22. Process Flow The process flow diagram for the VMR Frame 250 is shown in FIG. 23. The VMR Frame 250 supports the functional requirements identified for the VMR decision process: VMR Strategic Planning The VMR Strategic Planning activity 252 in concert with the MDA Module 134 and the FGIM Module 164 considers the financial and business requirements supplied by the customers, distribution infrastructure, POS history and the transportation factors in the Supply Chain Network data table 260 to evaluate various service contract options. The VMR contract parameters are then written to VMR Contract 262. Replenishment Planning The Replenishment Planning activity 270 working with the MDA 134 and the SFP Module 132 reviews the sell-through information and provides input to the FGIM Module 164 to generate the corresponding replenishment requirements. These requirements are refined according to the VMR Contract 262. Based on these inventory requirements, the VMR Contract 262 and the order fulfillment activity, the replenishment schedule is generated and written to VMR Data 272. Data Flow The data flow diagram for the VMR Frame 250 is shown in FIG. 24. The VMR Frame 250 generates the Replenishment Schedule report 280 listed earlier. VMR, also referred to as direct replenishment, is a growing agile logistics partnership agreement where the vendor takes on the responsibility of managing the inventory at the customer sites for the products it supplies, i.e., monitoring, planning, and directly replenishing the inventory in the customer's distribution network. In other words, under a VMR arrangement, it is the vendor who determines when stocks are to be replenished and in what quantities, rather than responding passively to orders placed by the retailer. This arrangement is usually typified by a contract which specifies the financial terms, inventory constraints, and performance targets such as service measures. VMR is almost invariably based on the availability of direct access to point-of-sale data and the customer's inventory positions. Such an arrangement can be mutually advantageous to the customer and the supplier. On the other hand, VMR requires the integration of inventory and transportation planning processes of the supplier and the customer. Although much has been written in the general literature about VMR as a concept (e.g., Wal-Mart's relationships with its suppliers) there are few known quantitative models, if any, to support VMR. Existing VMR systems are transaction oriented and provide little or no decision support capabilities. The VMR Frame 250 consists of a set of decision support tools that can be used in the development of VMR programs. The features offered by the VMR Frame 250 support the decision making processes in the VMR programs at both strategic and operational levels. More specifically, at the strategic level, the user can invoke the features provided by the Frame 250 to study of the feasibility of VMR programs; evaluate the terms of VMR contracts; and periodically review the overall performance of the VMR program. At the operational level, the user can invoke the Frame features to develop sell-through forecasts; obtain suggested replenishment quantities; revise replenishment quantities; and monitor sales and other VMR related statistics. In this section, we will provide the functional specification for the VMR Frame 250. The entire Frame 250 can be partitioned into three main parts: basic and VMR specific data maintenance, strategic planning and replenishment planning. It supports the following two functional requirements: VMR Strategic Planning: Evaluate financial and logistical tradeoffs in a VMR contract, and Comparative analysis of various service contract options; and Replenishment Planning: Review sell-through and determine inventory requirements at retailer's location, and Formulate the replenishment plan. The main decision modules to support the VMR Frame 250 include MDA 134, SFP 132, VMR and APP 160. We will discuss the functional specifications that are applicable to the manufacturing environment. Data Maintenance To support general functionality of the VMR Frame 250, the system should maintain two types of data: the Basic Structural Data and the Replenishment Data. In the following two sub-sections we discuss the details of these two sets of data. Basic Structural Data These include the essential data elements required to describe the basic characteristics of the products, distribution network, etc. This set of data are relatively stable and require only infrequent updates (e.g., at the time when the VMR program is being initialized, or when new models are being added to the program). These include: Distribution Network: Define the customer as well as the vendor's product distribution networks that are relevant to the VMR program. It identifies which product is being distributed from which vendor warehouse and which customer Distribution Center (or store) are assigned to each warehouse. Distribution Center (DC) Profile: Define the main attributes of a customer DC or a vendor warehouse including its location (city and state) information. Lead-times: Define the lead-time for product distribution between a given pair of locations and the corresponding transportation modes. Transportation Costs: Define the transportation costs for product distribution for given transportation modes. Product Profile: Define the main attributes of the products participating in the VMR program including their IDs and physical characteristics. It also specifies whether a product is currently in the VMR program. Product Replacement Relationship: Define the relationship between a current product and its predecessor (being replaced). This provides the basic information to establish a continuous demand stream for a pair of closely related products. Replenishment Data Replenishment data are more dynamic, and record the details about the replenishment activities as well as the characteristics of the VMR program itself. These include: Product and DC Watch List: A set of products and DCs that are defined by the user to be monitored by the system so that any special movements or activities can be detected and reported. Seasonality Factors: The set of factors calculated by the system or provided by the user to characterize the basic seasonal fluctuation patterns in the sales activities. Replenishment Orders (Receipts, In-transit, Incomplete, etc.): The detailed order status information that is recorded to capture the replenishment activities included in the program. Maximum and Average Inventory Levels: The targeted maximum and average inventory levels specified in the VMR contract. They can be used to monitor the current performance of the VMR program. Service Levels: The targeted customer service levels specified in the VMR contract. Delivery Frequency: The delivery frequency is defined by the user or the system and it specifies the frequency at which the products are replenished for a particular customer DC. Promotion Calendar: The calendar captures the relevant promotion activities. This information is then used to ensure that a sufficient additional amount is included in the regular replenishment quantity. Strategic Planning Strategic planning features mainly support VMR decisions during the initial program setup; important during VMR contract negotiation stages. They are also useful to provide critical operating parameters, e.g., replenishment frequencies. Finally, they are also needed to conduct long-term performance reviews. Therefore, the functions provided at the strategic level are addressing the issues which are of long-term importance, even though these decisions are not made so frequently. VMR Contract Setup During the initial stage of potential engagement in a VMR program, the conditions in the VMR contract are proposed, studied and negotiated. Under such circumstances, the user needs to evaluate the costs and benefits of many different program options. When the terms are conflicting, tradeoffs have to be made. In addition, one also has to choose a set of operating parameters and procedures which optimize total cost measures while satisfying given constraints. The features provided below are to support these decision making problems. For a product/product group, a customer DC, and a delivery frequency defined by the user, the system will provide the computed relationship between expected service level and maximum (average) inventory level. Such a relationship will also be useful for the user to evaluate what-if Scenarios and can be used in other features in this Frame (e.g., the Replenishment Planning below). Compute and display expected service level for the maximum inventory requirement defined by the user. Estimate and display the proper inventory level for a given service level defined by the user. When evaluating the optimal VMR operating parameters or conditions in the contract, the system can help the user to either check the compatibility of a set of constraints including service level, inventory level and delivery frequency, or select an optimal set of these parameters after the evaluation of all feasible combinations. To use this feature, the user first needs to choose the product/product group and the DC of interest. For a given replenishment scenario (a given set of delivery frequency, target inventory level and customer service level), the system will estimate the total cost including customer DC inventory carrying cost, transportation cost and manufacturing plant inventory carrying cost. Different replenishment Scenarios can be generated based on different values of delivery frequency, target average inventory level and target customer service level. In order to compare these different options without using total projected costs like the one suggested in the feature above, the system will compute key statistics such as expected inventory levels at customer DCs and manufacturing plants. By comparing these statistics, a better replenishment scenario can be identified. Contract Parameter Monitoring and VMR Program Review After a VMR program has been setup and the execution started, it requires constant monitoring of the key policy parameters and performance measures. If there are substantial changes, it is critical to report them back to the users. This is because the optimal operating parameters in the VMR program set at the strategic level are obtained under certain assumptions about these key indicators. In addition, periodically, the management will be interested in the actual effectiveness of the VMR program. To support such program reviews, the system will record and generate management reports regarding the actual performance of the VMR program compared to the inventory and customer service level targets set in the VMR contract. Periodically (which can be defined by the user), the system will compute the mean and standard deviation of the sell-through for a given product of a given customer DC. The resulting numbers can then be compared to the historical norm defined by the user, the quantitative modeling assumptions, or recorded by the system. If the mean and standard deviation are outside of the defined range, then the user has to be informed through a product sales exception report or other similar reports. The user will be asked to define the following: Frequency of such evaluation; Historical norm of the mean and standard deviation; and The ranges of the mean and standard deviation. One of the key objectives of any VMR program is to reduce the total inventory levels at different parts of the supply chain. The system will compute and record average inventory levels and compare it to maximum and average inventory targets. The results can then be reported to the user as requested. When the inventory level of a given product/product group at a customer DC is much higher than needed, part of the inventory should be considered as excess. The system will report the list of products whose inventories are in excess. These products then will be off the replenishment product list until the inventory levels return to a normal range. During these periods, the production and many other logistics operations planning will have to be notified about the reduction in planned quantities. Replenishment Planning This is to support more operational decision problems on a regular basis after the VMR program has started its execution. During this stage, the main concerns of the user will be shifted to those of a more operational flavor such as the generation and revision of the replenishment order to satisfy target customer service levels and maximum inventory constraints. In addition, in order to ensure the validity of the decision support models and prepare the decision makers for changes in the market place, the system will monitor certain operational indicators relating to the VMR program. The indicators and purpose of this monitoring are distinctively different from the monitoring and review function offered at the strategic level. Sell-Through and Demand Orientation Forecasts Before we can start to use the system to generate replenishment orders, a set of sell-through forecasts have to be developed. We will use the models developed in SFP 132 using POS as the primary data source. On the other hand, the production planner at the manufacturing vendor needs to know longer term forecasts to plan for future capacities. To that end, the system allows the user to develop and examine not only the replenishment quantity of the next replenishment cycle but also to extend several periods ahead so that these longer term forecasts can also be estimated and used for other (e.g., manufacturing) planning purposes. Based on the sell-through data provided by the customer for a given product/product group at a customer DC, the system will generate sell-through forecasts including mean and standard deviation for any given product at a customer DC. The actual forecast algorithm will invoke an appropriate one specified in the SFP Module 132 which should consider trend, and seasonality among other basic aspects of the data stream. In case of a product having too little sell-through history, the system will use the product replacement relationship defined to establish more continuous sell-through history. In addition, the system will also permit the user to select an appropriate length of historical data to account for abnormal sales activities for the product. The system will also generate longer term replenishment requirements for the demand orientation for a given product so that the user can plan for the longer term demands for the product. To generate medium to long term forecasts, the system will first forecast the sell-through for the specified time periods by invoking appropriate forecasting algorithms in the SFP Module 132. Then, a set of replenishment quantities will be generated using the replenishment algorithm in the VMR module. These replenishment quantities will then become the demand forecasts for the product. Replenishment Order Generation The generation of replenishment orders is the main functionality of the replenishment planning of the VMR Frame 250. The main objective of the functionality is to provide the user with an initial set of replenishment quantities for a set of products with the consideration of the sell-through forecasts as well as VMR specific operating parameters. The quantities will then be approved by the user and converted into actual purchase orders. Based on the forecasts of the future sell-through, user defined VMR operating parameters (e.g., customer service level, maximum inventory level and delivery frequency), and other related indicators (e.g., last reported customer DC inventory level), the system will generate a suggested replenishment quantity for a future replenishment date. If the product model year changes are regular, then it is necessary to treat the replenishment quantity needed for product (or VMR program) initialization and termination differently from the regular replenishments. Therefore, the above feature has to be modified to be applicable to these settings: Set Initial Replenishment Quantities: The main difference between the initial replenishment quantity setup and the regular one is that it may require additional quantities to fill customer DCs or stores. In addition, because there is no sell-through history available for these new products, the history for the replaced products will have to be used in the computation. It is also necessary to set a time frame for the computation algorithm to use a new product's data when it accumulates enough data of its own. Balance-out at the End of a Season: At the end of a selling season, a product needs to be phased out. In such a situation, the system will not generate any further replenishment quantities for the product unless the user decide to overwrite the suggested (zero) quantities for a special reason. For a given customer DC, when the products are being considered for replenishment, the system will help the user set joint replenishment orders so that the total cost for the replenishment batch can be minimized. The basic logic is to add or delete products included in a replenishment batch to optimally use the transportation means while maintaining satisfactory customer service level and inventory level. The system will also automate the replenishment quantity generation for a set of products selected by the user. This feature is useful especially when the number of products in the VMR program is relatively large and the user prefers to work only on exceptional issues rather than examining the details of each product's replenishment activities. Replenishment Order Revision After the initial replenishment quantity has been generated for each product, the user may be interested in examining the entire or only a selected set of products to make sure that the soft information can be reflected in the actual replenishment orders. In addition, a number of constraints such as product availability and production capacity will also have to be taken into consideration. The objective of the features listed below is to help the user revise the replenishment orders with relevant analysis and search support tools. The user can define a set of exceptional report generation criteria so that the system can search for and display the products falling into the range. The sample user-defined criteria will include Mean and standard deviation exceeding certain limits of the historical norm The customer DC inventory exceeding the maximum inventory level after the suggested replenishment quantity arrives For a given replenishment quantity (either recommended by the system or input by the user), the system will estimate and display the probability of stock-outs. To compute the probability value, a search algorithm is needed in addition to the relationship between inventory quantity, customer service level and delivery frequency. The user can use the feature to evaluate whether the replenishment quantity suggested is satisfactory or not. Most of the replenishment quantities discussed here are appropriate for non-promotional sales. When a promotion for a product is planned, the user should be informed so that the final replenishment quantities can incorporate additional quantities due to the promotion. The objective of this feature is to identify promotion events during a given replenishment review period and help the user incorporate additional quantity for the events. Before the replenishment orders can be finalized, the DSS 10 will make sure that the vendor can supply the required quantities in the specified time frame. If the replenishment order shipment date is close to the review date, then the product (finished goods) availability will be checked; and if the shipment date is further into the future, then the production capacity will be examined. In order to properly make tradeoffs between different replenishment Scenarios, the system will estimate the total cost (including the inventory and transportation among others) for a given set of replenishment quantities. The cost will be computed automatically as the user is making modifications in the replenishment orders. To reduce the transportation cost, a rough-cut truckload planning tool will be provided to the user so that the room left on a truck can be filled by other most-needed products for the same customer DC. The underlying logic is to build a truckload of shipment | ||||||
