Abstract:
A system and method are described for intelligently sourcing demand forecasts within a supply chain management (“SCM”) system based on a constrained supply chain model, in light of material and resource constraints. For example, a computer implemented method according to one embodiment of the invention comprises: calculating a demand forecast identifying anticipated demand for a product over a specified time period; identifying current sales orders for the product with delivery dates scheduled during the specified time period; generating an open forecast for the product based on the current sales orders and the anticipated demand; and sourcing different percentages of the open forecast from different plants, the percentages selected based on supply chain material and/or resource constraints. In addition, after the demand forecast is sourced, one embodiment of the invention employs additional techniques for intelligently sourcing new sales orders entering the SCM system.

Description:
BACKGROUND  
       [0001]     1. Field of the Invention  
         [0002]     This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for sourcing a demand forecast within a supply chain management (“SCM”) system.  
         [0003]     2. Description of the Related Art  
         [0004]     Certain software applications are designed to comprehend complicated scheduling tasks. For example, a supply-chain-management (“SCM”) software application is typically designed to comprehend the resources in a supply chain (e.g., raw materials, manufacturing equipment, distribution, warehousing, etc) and schedule their usages (also referred to as “activities”) so that a specific “supply” of product can be provided at one or more places at specific times to meet the anticipated “demand” for the product.  
         [0005]     More advanced SCM applications provide functions for intra- and inter-company supply chain planning and for scheduling and monitoring of associated supply chain processes. For example, the assignee of the present application has developed an advanced supply chain management platform known as the Advanced Planner &amp; Optimizer (“APO”) which, as described in Gerhard Knolmayer, et al., S UPPLY  C HAIN  M ANAGEMENT  B ASED ON  SAP S YSTEMS  (hereinafter “Knolmayer”), includes different modules for implementing various interrelated SCM functions. These modules include a demand planning (“DP”) module, a supply network planning (“SNP”) module, a production planning and detailed scheduling (“PP/DS”) module, a transportation planning/vehicle scheduling (“TPNS”) module and an available to promise (“ATP”) module. The following is a brief overview of each of these components.  
         [0006]     The ability to accurately forecast demand is an important precondition to any production planning schedule. With this goal in mind, the DP module attempts to determine the demand for a product over a specified time period. By way of example,  FIG. 1  illustrates a DP module  101  which has anticipated the demand for a particular product (P 1 ) by a particular customer (C 1 ) for January (100 units), February (150 units) and March (100 units). As indicated in  FIG. 1 , current demand planning techniques are largely based on empirical data  100  for a given product (e.g., historical demand data stored within an archiving system or data warehouse).  
         [0007]     SNP and PP/DS both fall into the general category of “advanced planning and scheduling” or “APS” which involves the planning and scheduling of materials and resources within the supply chain. SNP differs from PP/DS in terms of the time horizon used for planning and scheduling. SNP is used for tactical (i.e., midterm) planning, whereas PP/DS is used for operational (i.e., short-term) planning. For example, a typical planning horizon for SNP may be in the range of 3-6 months whereas a typical planning horizon for PP/DS may be in the range of 1-7 days.  
         [0008]     The TP/VS module employs techniques to optimize the delivery of products using different transportation routes and vehicles. It enables manufacturers, retailers, and logistics providers to coordinate transportation resources via the Internet and to synchronize transportation decisions and activities. The transportation planning component of TPNS focuses on medium- to long-term planning whereas the vehicle scheduling component focuses on short-term planning and routing.  
         [0009]     Finally, the ATP module is responsible for determining whether a product can be promised by a specified delivery date in response to a customer request. If a given product is not in stock, ATP coordinates with other modules such as PP/DS to determine whether the product can be procured from alternate sources and/or manufactured in time to fulfil the customer request.  
         [0010]     One problem which exists with current SCM systems is the lack of coordination between the demand planning component and the other system components. As mentioned above, the demand planning forecast is typically propagated through the supply chain based on empirical rules rather than in an optimized manner. Current demand planning forecasts do not factor variables such as material and resource constraints existing along various levels of the supply chain. As a result, current systems are incapable of intelligently sourcing the demand forecast in light of these constraints. In addition, once a demand forecast is sourced, current systems do not provide adequate coordination when sourcing subsequent sales orders entering the system. Accordingly, what is needed is an SCM system which employs more intelligent sourcing decisions using improved communication and coordination between demand planning and other SCM system components.  
       SUMMARY  
       [0011]     A system and method are described for intelligently sourcing demand forecasts within a supply chain management (“SCM”) system based on a constrained supply chain model, in light of material and resource constraints. For example, a computer implemented method according to one embodiment of the invention comprises: calculating a demand forecast identifying anticipated demand for a product over a specified time period; identifying current sales orders for the product with delivery dates at the ship-to party scheduled during the specified time period; generating an open forecast for the product based on the current sales orders and the empirically calculated DP forecast; and sourcing the open forecast from different plants, the percentages selected based on supply chain material and/or resource constraints. In addition, after the demand forecast is sourced, one embodiment of the invention employs additional techniques for intelligently sourcing new sales orders entering the SCM system.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0012]     A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:  
         [0013]      FIG. 1  illustrates demand planning used in prior art supply chain management systems.  
         [0014]      FIG. 2  illustrates a system for sourcing a demand forecast according to one embodiment of the invention.  
         [0015]      FIG. 3  illustrates a method for sourcing a demand forecast according to one embodiment of the invention.  
         [0016]      FIGS. 4   a - c  provide an example in which a demand forecast is sourced taking existing sales orders into consideration.  
         [0017]      FIGS. 5   a - b  proceed with the example in determining open forecast values for different plants.  
         [0018]      FIG. 6  illustrates one embodiment of the invention in which transportation orders used as an intermediate data format for sourcing a forecast.  
         [0019]      FIGS. 7   a - b  illustrate how product allocations within available to promise module are modified based on open forecast values.  
         [0020]      FIG. 8  illustrates an exemplary computer system on which embodiments of the invention may be executed.  
     
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0021]     Described below is a system and method for performing bucket-oriented capacity checks within a supply chain management (“SCM”) system. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. For example, although many of the embodiments described herein are based on the APO and/or R/3 architectures developed by the assignee of the present application, the underlying principles of the invention are not limited to any specific SCM architecture. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the present invention.  
       Embodiments of the Invention  
       [0022]     Rather than simply propagating a demand forecast through the supply chain based on empirical rules as in prior SCM systems, one embodiment of the invention employs optimization techniques to source demand forecasts based on a constrained supply chain model (i.e., taking material and resource constraints into consideration). In addition, after the demand forecast is sourced, one embodiment of the invention employs techniques for intelligently sourcing new sales orders.  
         [0023]      FIG. 2  illustrates one embodiment of the invention which includes a forecast sourcing module  200  for executing the forecast sourcing techniques described herein. As illustrated, the forecast sourcing module  200  is part of a larger SCM application  210  executed on an application server  230 . To perform its calculations related to forecast sourcing, the forecast sourcing module  200  communicates with various other modules within the SCM application  210  including an available to promise (“ATP”) module  202 , a supply network planning (“SNP”) module  203 , a transportation planning/vehicle scheduling (“TP/VS”) module  204 , and a demand planning (“DP”) module  205 . In addition, in one embodiment, the forecast sourcing module  200  communicates with existing RI 3  systems  206  (e.g., to receive data related to new sales orders). The SCM system also includes an SCM database  220  for storing persistent data related to the various SCM processes. In one embodiment, each of the modules illustrated in  FIG. 2  are implemented as program code stored in memory and executed by a central processing unit on an application server  230  (or spread across multiple application servers). Once again, however, the underlying principles of the invention are not limited to any specific hardware/software or SCM application architecture.  
         [0024]      FIG. 3  illustrates a method for sourcing a forecast according to one embodiment of the invention. The method includes a first section  300  for sourcing a customer-specific forecast and a second section  305  for sourcing new sales orders once the customer-specific forecast has been generated. Within the first section, at  301 , the DP module  205  initially calculates a monthly customer-specific demand forecast for a particular product, similar to that illustrated in  FIG. 1  (e.g., using historical demand data). In one embodiment, the demand forecast is calculated in the same manner as in previous SCM systems including, but not limited to, APO.  
         [0025]     After the demand forecast is generated, at  302 , existing customer-specific sales orders for the product are identified so that they can be factored in to the calculation of the open forecast. By way of example, as illustrated graphically in  FIG. 4   a  a customer C 1  has previously entered sales orders scheduled for a January delivery in the amount of 40 units: 10 units which are scheduled to be sourced from plant P 1  and 30 units which are scheduled to be sourced from plant P 2 . At  303 , the sales orders are subtracted from the demand forecast to arrive at “open forecast” value according to the following equation: Open Forecast=Customer-Specific Forecast−Cumulated Sales Order Quantities. Thus, in the example shown in  FIG. 4   a  : Open Forecast=100−(30+10)=60. For the purpose of illustration, these values are arranged within the table shown in  FIG. 4   b.  If the cumulated sales order quantities is greater than the customer-specific forecast, then the open forecast is set equal to zero.  
         [0026]     In addition, in order to protect the sourced forecast orders from being consumed by the already-existing sales orders at each plant, one embodiment of the invention creates “dummy” forecast orders for each existing sales order within the SCM application  210 . For example, as shown in  FIG. 4   c,  dummy forecast  402  is created with a value equal to sales order  401  to protect sourced forecast order  403  from being consumed by sales order  401 ; and dummy forecast  405  is created with a value equal to sales order  404  to protect sourced forecast order  406  from being consumed by sales order  404 . The “descriptive characteristics” for each of the sales orders and forecast orders define the specific product, plant, and customer associated with the order.  
         [0027]     Essentially, the forecast orders (identified with order type “FE”) are created at the plant location when the DP forecast at the customer location is propagated to the plant locations. These forecast orders are essentially placeholders for subsequent incoming sales orders (order type “BM”) in that they represent a demand quantity for the SNP process. Therefore, in order that the demand quantity does not increase disproportionately, for every incoming sales order, the net quantity of the forecast order decreases by the net quantity of the incoming sales order. This takes place for every product at the plant location. This process of reduction in the forecast order quantity is known as “consumption.” 
         [0028]     “Dummy” forecast orders are a new order type introduced in the present application. When DP forecast at the customer location is sourced to the plant locations, by default a consumption process is called. This call to the consumption process would decrease the net quantity of the sourced forecast orders by the net quantity of the sales order at each plant location. This behavior would be inconsistent with the principle of the sourcing process because the net quantity after sourcing would be less than the net quantity before the sourcing takes place. In order to avoid this inconsistency, the sourced forecasts orders have to be “protected” from the existing sales orders at the plant locations. This is realized by creating dummy forecast orders (order type “FA”) which are immediately consumed by the existing sales orders thereby preventing a consumption of the sourced forecast orders.  
         [0029]     In one embodiment, after the dummy forecast orders have been created, and the open forecast has been calculated, these values are provided to an optimizer within the SNP module  203  which, at  304 , attempts to source the open forecast in the most efficient manner possible, given the current material and resource constraints. The SNP optimizer is a well known component of the SNP module  203  of APO.  
         [0030]     An exemplary allocation of the open forecast is illustrated in  FIG. 5   a,  which shows  20  units of the open forecast sourced from plant P 1  and  40  units of the open forecast sourced from P 2 . As indicated in the table in  FIG. 5   b,  this results in a total allocation (i.e., sourced forecast+sales orders) of 30 from plant P 1  and 70 from plant P 2 .  
         [0031]     In one embodiment of the invention, the SNP module  203  does not create the forecast orders directly. Rather, it creates “transportation orders” representing the forecast orders which would normally be processed by the TPNS module  204 . The forecast sourcing module  200  then intervenes and converts the transportation orders into forecast orders with descriptive characteristics. The descriptive characteristics provide a means to identify the customer location associated with each forecast order thereby facilitating a consistent consumption process. This technique is illustrated in  FIG. 6  which shows transportation orders  601 ,  602 , generated by the SNP optimizer  600  based on sales orders  401 ,  404 ; dummy forecast orders  402 ,  405 ; and the demand forecast (100 units). Each of the transportation orders  601 ,  602  include a source P 1 , P 2  a destination C 1 , C 2  and an amount (i.e., 20 units for transportation order  601  and 40 units for transportation order  602 ). The transportation orders  601 ,  602  are then converted to sourced forecast orders  603 ,  604  by the forecast sourcing module  200 . Each transportation order has an associated start date and a delivery date. In one embodiment, the transportation orders are generated so that their delivery date coincides with the start of the time-bucket of the demand forecast (e.g., January 1 in the above example). Using the transportation order mechanism described above, the forecast sourcing process may be in integrated within current APO systems in a transparent manner (i.e., without significant modification to existing modules such as SNP modules  203  and TPNS modules  204 ).  
         [0032]     Turning again to the overall process shown in  FIG. 3 , at  305 , one embodiment of the invention sources new sales orders based on the sourcing decision for the customer-specific forecast. The sales orders are created and processed using the descriptive characteristics mentioned above (i.e., customer ID, product ID, plant ID) and are checked against the customer-specific allocations.  
         [0033]     By way of example,  FIG. 7   a  illustrates an exemplary ATP global product allocation table with time-buckets divided into weeks. The numbers within each time bucket indicate the number of units of a product available to be promised during that week. For example, in week 1 (W1), the ATP module can promise 100 units to customer C 1  for delivery from plant P 1  and can promise 65 units for delivery from plant P 2 .  
         [0034]     As indicated in  FIG. 7   b,  in one embodiment of the invention, the open customer-specific forecast for each plant is added to the product allocation values. For example, the open forecast of 20 for customer C 1 , plant P 1  is added to the product allocation of 100 units in week 1, resulting in a new value of 120 units. Similarly, the open forecast of 40 for customer C 1 , plant P 2  is added to the product allocation of 65 in week 1, resulting in a new value of 105 units. As a result, if a new sales order of 110 units is received (e.g., from R/3), the order may be promised to the customer and sourced from a single plant P 1  (resulting in a remaining product allocation of 120−110=10 for that plant). Prior to the forecast sourcing techniques described herein, only 100 units would show up as being “available” to promise from plant P 1  and the remaining 10 would need to be sourced from another plant P 2 .  
         [0035]     ATP product allocations typically operate on weekly buckets as described above. One embodiment of the invention automatically performs the necessary adjustments associated with a transition from a monthly to a weekly time bucket profile (i.e., subdividing the monthly bucket into a plurality of weekly buckets). This conversion is respected while updating the ATP Allocation structures. Once the allocation structures are appropriately updated, subsequent sales orders are sourced based on the updated values and the standard process takes over from this point on.  
         [0036]      FIG. 8  is a block diagram of an exemplary computing system  800  that can execute program code stored by an article of manufacture. It is important to recognize that the computing system block diagram of  FIG. 8  is just one of various computing system architectures on which the embodiments of the invention may be implemented. The applicable article of manufacture may include one or more fixed components (such as a hard disk drive  802  or memory  805 ) and/or various movable components such as a CD ROM  803 , a compact disc, a magnetic tape, etc. In order to execute the program code, typically instructions of the program code are loaded into the Random Access Memory (RAM)  805 ; and, the processing core  806  then executes the instructions. The processing core may include one or more processors and a memory controller function. A virtual machine or “interpreter” (e.g., a Java Virtual Machine) may run on top of the processing core (architecturally speaking) in order to convert abstract code (e.g., Java bytecode) into instructions that are understandable to the specific processor(s) of the processing core  806 . In one particular embodiment, the computing system  800  is the SAP Web Application Server currently available from SAP AG.  
         [0037]     It is believed that processes taught by the discussion above can be practiced within various software environments such as, for example, object-oriented and non-object-oriented programming environments, Java based environments (such as a Java 2 Enterprise Edition (J2EE) environment or environments defined by other releases of the Java standard), or other environments (e.g., a .NET environment, a Windows/NT environment each provided by Microsoft Corporation).  
         [0038]     Embodiments of the invention may include various steps as set forth above. The steps may be embodied in machine-executable instructions which cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.  
         [0039]     The present invention may also be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).  
         [0040]     Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. For example, although the description above focused on single-activity resources, the same general principles apply to other resources (e.g., multi-activity resources). Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.