Available to promise allocation optimization tool

A distributed, network-based system, method, and computer program product determines an optimal allocation of available to promise components in a supply chain. An aggregate demand request is generated by a demand entity intelligent agent. The aggregate demand request is propagated via a network throughout the supply chain to a plurality of supply entity intelligent agents. The supply entity intelligent agents respond with an evaluation of available to promise supply capability. Optimal allocation of the available to promise supply is made by calculating a sequence of squared set solutions of unit demand problems using a message-based communications protocol between the demand entity and supply entity intelligent agent.

BACKGROUND OF THE INVENTION

The invention relates generally to computer implemented supply chain planning and decision support tools, and more particularly to a tool used to manage available to promise resources in a supply chain.

Demand-Supply Rationalization (DSR) software packages are used in manufacturing to ensure that supply is in some sense optimally allocated to prioritized demand. With reference toFIG. 1, these packages can be applied to a supply chain10, illustrated to comprise three levels or tiers: a Tier0or final assembly level, a Tier1or subassembly level, and a Tier2or component level. It will be understood that the supply chain10could have as few as two levels, up to an arbitrarily large number N of levels. Tier1includes a demand entity12, while Tier1is illustrated to include first and second supply entities14and16, respectively. The number of Tier1supply entities can range from one to an arbitrarily large number M. Demand entity12is illustrated to require subassemblies from both the first and second supply entities14and16to produce a final assembly. Tier2is illustrated to include third, fourth, and fifth supply entities18,20, and22, respectively. As with Tier1, the number of Tier2supply entities is arbitrary. First supply entity14is illustrated to require components from both the third and fourth supply entities18and20to produce a first supply entity subassembly. Second supply entity16is illustrated to require components from only the fifth supply entity22to produce a second supply entity16subassembly.

It is known to mathematically or heuristically model a given multi-level and/or multi-supplier per level supply chain10using various techniques. For example, with reference toFIG. 2, a centralized supply chain model30considers the entire supply chain10as a single logical entity, functioning as a vertically integrated supply chain. The centralized supply chain model30includes a demand entity database32operably coupled to a central model48. The centralized supply chain model30further includes Tier1and Tier2supply entity databases36and38, respectively, which are operatively coupled to a central database34via Tier1and Tier2supply entity input bridges40and42, respectively. Information contained in the Tier1and Tier2databases36,38is operated on by Tier1and Tier2processes44and46, respectively. Communication of information from the supply entity databases36,38to the central database is characterized by a time lag. There are at least three components of the time lag: 1) job scheduling, that is, jobs are setup to run at fixed points in time which vary from enterprise to enterprise thereby creating a gap from the start of the first transmission job at the first enterprise to the start of the last transmission job at the last enterprise; 2) per job transmission time, that is, bulk transfer of large data sets can take minutes to hours to complete; and 3) process evaluation time, that is, a business review process50requires time to evaluate step specific results before proceeding to the next step in the end to end process. The central model48receives data from the central database34. Output of the central model48is reviewed in the business review process50(typically performed by a human user). After a time lag, results of the analysis of the centralized supply chain model30(for example, firm orders for available to promise inventory) is communicated to the Tier1and Tier2supply entities via Tier1and Tier2supply entity results bridges52and54, respectively.

The central model48thus receives all relevant data, from all levels, including all supply entities and the demand entity. With complete information regarding demand needs and supply capability, the central model48is capable of performing an end to end analysis over all levels and suppliers, and to develop an optimal allocation of supply to demand using either conventional heuristic or mathematical techniques, such as linear programming, to determine the allocation of components to maximize (that is, optimize) the number of end products ultimately produced by the demand entity12based on the components supplied in the demand request.

As a second example of known methods for modeling a supply chain10, with reference toFIG. 3, it is known to use a so-called “loosely coupled” (or “disconnected”) supply chain model60. Unlike the centralized supply chain model30, the loosely coupled supply chain model60does not require a central database or supply entity input or results bridges. In the loosely coupled model60, allocation of supply proceeds from one tier to the next, working from the lowest tier to the top tier. Generally speaking, given a leveli+1supply support position, and a leveli−1, demand, each levelientity runs a local allocation of supply to demand. The resultant levelisupport position relative to leveli−1customer demand is then passed back to leveli−1, customers. For example, in the context of the loosely coupled model60illustrated inFIG. 3, a demand request is generated by a Tier0demand entity process62. The demand entity process62is operatively coupled to a demand entity database64. The demand request is communicated to Tier1supply entity process66via a zone1dialogue68within a collaboration zone70. That level0customer demand is compared to a level2(Tier2) supply support position. That is, a Tier2process72queries Tier2database74, determines the supply support position, and communicates the supply support position to the Tier1process66via a zone2dialogue76within the collaboration zone70. The supply support position information, combined with information stored in a Tier1database78, allows the Tier1process66to provide a response to the demand request.

An advantage of the centralized supply chain model30is its ability to provide an optimal solution for allocation of available to promise inventory. A central disadvantage of the centralized supply chain model30is the relatively high expense (compared to the loosely coupled supply chain model) of providing, maintaining, and using the input and result bridges40,42,52, and54, and central database34.

While there are development and operations savings as well as flexibility gains to be realized in use of a loosely coupled model60, a significant disadvantage with use of the loosely coupled model60is that such models are unable to provide a closed, end to end optimal allocation of available to promise inventory. Given current solver techniques, end to end optimum allocation of supply to demand requires inter-level and intra-tier visibility to materials and/or capacity constraints. While this visibility is necessary, it is not sufficient to permit calculation of an optimal allocation of available to promise inventory. Coordinated inter-level and intra-tier allocations are required if the allocation result is to be optimum in terms of the top level demands and business rules. The centralized supply chain model30has the necessary visibility and sufficient control to effect end to end optimum allocation of supply to top level demand. The loosely coupled supply chain model60does not. Known loosely coupled supply chain models60provide suboptimal end to end allocations.

Given a trend away from physical or logical vertically integrated supply chains and single entity models toward dynamic multi-player loosely coupled supply chains, the inability of a loosely coupled model to develop a global optimum allocation of supply to demand is a significant and challenging problem.

Furthermore, there is a second disadvantage to the loosely coupled models60. Disconnected models60typically require days to iteratively develop the equivalent of a closed-form, optimal response to a new top level demand statement. Many, if not most, businesses can ill afford to wait days or perhaps even weeks to respond to a demand change. Hence the time lags inherent in loosely coupled models60pose a significant business problem.

A need exists, therefore, for an available to promise inventory allocation tool providing both the time-efficient closed-form optimal allocation solutions characteristic of centralized supply chain models as well as the cost and flexibility benefits of the loosely coupled supply chain models.

BRIEF SUMMARY OF THE INVENTION

Briefly stated, in a first aspect the invention is a computing system for providing an optimal allocation of available to promise components in a supply chain having a demand entity and a plurality of supply entities. The computing system comprises a process controller operably coupled to a demand entity data base and a message server. The process controller is also operably coupled via a network to a plurality of supply entity process servers, supply entity databases, and supply entity message clients. A solver product is provided, responsive to material supply information, product supply rules, and supply priorities. The solver product includes a demand entity intelligent agent and a plurality of supply entity intelligent agents. The solver product also includes means for generating an aggregate demand request including priority information and requested delivery date information for components to be supplied to the demand entity by one or more of the plurality of supply entities. The solver product further includes means for propagating the demand request throughout the supply chain, so that the plurality of supply entity intelligent agents each associated with one of the plurality of supply entities is informed of the demand request for components supplied by that supply chain entity. Means are further provided for generating and communicating to the process controller an evaluation of available to promise supply capability from the plurality of supply entity intelligent agents. Also, means for generating an optimal allocation of available to promise components are provided.

Preferably, the means for generating an optimal allocation of available to promise components includes means for generating a sequence of demand problems, each demand problem being evaluated end to end through the supply chain, resulting in a series of squared set solutions. Preferably, the demand problems are unit demand problems.

The means for generating the sequence of demand problems preferably includes means for generating a message regarding a single demand item over the network to each of the plurality of supply entity agents, the message providing an inquiry of whether the supply entity can supply a quantity of the single demand item.

Further preferably, the intelligent agent of each of the plurality of suppliers generates a response to the message providing information regarding whether the supplier can supply the quantity of the single demand item. The network is preferably one of the Internet, an intranet, or a wide area network. The demand entity intelligent agent preferably further includes means for communicating acceptance of available to promise components based upon the optimal allocation.

DETAILED DESCRIPTION OF THE INVENTION

As used herein, when introducing elements of the present invention or the preferred embodiment(s) thereof, the articles “a”, “an”, “the” and “said” are intended to mean that there are one or more of the elements. An “intelligent agent” is a specialized software entity which autonomously performs tasks on behalf of users based on instructions given to it by the users, including communicating and exchanging data with other intelligent agents. “Available to Promise” (or ATP) is uncommitted existing inventory (or uncommitted planned inventory expected to be available by a desired delivery date). A “squared set” solution to a demand request means that sufficient Available to Promise inventory has been identified to satisfy the total demand.

Referring to the drawings, shown inFIGS. 4-6is a first presently preferred embodiment of an Available to Promise allocation optimization tool. With particular reference toFIG. 4, an ATP allocation optimization system100models a supply chain10having an arbitrary number of Tiers0through N. The supply chain10includes demand entity in Tier0, a first supply entity in Tier1(although the number of Tier1supply entities is arbitrary), an arbitrary number of supply entities (not illustrated) in Tiers2through N−1 (not illustrated) and an Mth supply entity in Tier N (an arbitrary number M of supply entities can exist in Tier N). In one preferred embodiment, hardware elements of the system100comprise a demand entity database server102, a demand entity process controller104, and a demand entity message server106. A demand entity intelligent agent322runs on the demand entity process controller104. The demand entity database server102, demand entity process controller104, and message server106are operatively coupled to one another and to a message bus or network110. The network110may be any conventional electronic communications network such as the Internet, an intranet, or a wide area network.

The system100further comprises a Tier1supply entity database server120, a Tier1supply entity process server122, and a Tier1supply entity message client124, all associated with the Tier1supply entity, and all operatively coupled to one another and to the network110. A Tier1supply entity intelligent agent324runs on the Tier1supply entity process server122.

Though not illustrated, each additional supply entity in each additional Tier1through N similarly has associated with it a supply entity database server, a supply entity process server, and a supply entity message client. For example, as illustrated, in Tier N, the Mth supply entity has a database server130, a process server132running a supply entity intelligent agent326, and a message client server134, all operatively couple to one another and to the network110.

With reference toFIG. 4as well as toFIGS. 5 and 6, the system100further comprises a solver product300, including the software associated with the demand entity and supply entity intelligent agents322,324, and326. The solver product300is responsive to material supply information, product supply rules, and supply priorities to determine an optimal allocation of ATP inventory (that is, an allocation of ATP inventory which maximizes total production of end products by the demand entity). The solver product300executes an ATP allocation optimization method200. The solver product300includes means (first computer program code) for executing a step202of the method200of generating an aggregate demand request including priority information and requested delivery date information for components to be supplied to the demand entity by one or more of the plurality of supply entities. The solver product300further includes means (second computer program code) for executing a step204of the method200of propagating the demand request throughout the supply chain via the network110so that each of the plurality of supply chain entities is informed of the demand request for components supplied by that supply chain entity.

Still further, the solver product300includes means (third computer program code) for executing a step206of the method200of generating and communicating an evaluation of available to promise supply capability for each of the supply entities. The evaluation is made by each supply entity intelligent agent reviewing information resident in the associated supply entity database.

The solver product300further includes means (fourth computer program code) for executing a step208of method200of generating an optimal allocation of the ATP inventory based on the ATP supply capability. Preferably, the means for generating the optimal allocation of ATP inventory includes means for generating and communicating a sequence of demand problems. Preferably, the demand problems are sequentially incremented by a predefined amount. Each demand problem is evaluated end to end though the supply chain10, resulting in a series of squared set solutions. Preferably, system100further includes means (fifth computer program code) for executing a step210of method200of communicating acceptance of ATP components to the plurality of supply entities.

With reference now toFIG. 6A, the solver product300may be represented by a top level flowchart310illustrating three fundamental processes: an aggregate demand explode process330; an aggregate supply response process332; and an allocation of supply process334. These three processes330,332, and334are accomplished by the exchange of a plurality of messages140which are transferred between the message server106and message clients124,134. Each message140corresponds to a vector of information which preferably specifies:

a. customer supplier relationships or, from a network point of view, the sender and receiver of the message;

b. a sequence ID to uniquely identify the message and enable a response to trace back to a request;

c. message directive which identifies the process behavior that's driven by the message;

d. demand ID, that is a specific final assembly, sub assembly, or component;

e. demand priority or relative business value of the demand;

f. customer demand quantity; and

g. supplier commit quantity, that is level of demand supported.

The exchange of messages140is accomplished by a network incoming message evaluation process340and a network outgoing message generation process380. With reference toFIG. 6B, relative to the network incoming evaluation process340, the message directive of item c. of the message140information described above is one of a number of sub-processes:

a. a cascade demand explode evaluation sub-process344;

b. an evaluation of available supply sub-process346;

c an evaluation of multiple sources for available supply sub-process348;

d a commitment of a reserved supply sub-process350;

e. a supply response request sub-process352;

f. a request of multiple sources for a supply response sub-process354;

g. a release of a reserved supply sub-process356;

h. a response to a single source availability check sub-process358; and

i. a response to a multi-source availability check sub-process360;

j. a support evaluation completion message evaluation sub-process362.

Incoming messages140are identified and routed to the appropriate tier using an identification and routing sub-process342.

With reference now toFIG. 6C, the outgoing message generation process380comprises one of a plurality of sub-processes:

a. an upstream cascade demand explode response sub-process382;

b. an upstream supply availability check response sub-process384;

c. a multi-source supply availability check response sub-process386;

d. an upstream commitment of reserved supply response sub-process388;

e. an upstream supply response request sub-process390;

g. a downstream response to an availability check sub-process394;

h. an upstream release of reserved supply sub-process396;

i. a downstream multi-source response to an availability check sub-process398; and

j. a support evaluation complete message generation sub-process400.

Outgoing messages140are identified and routed to the appropriate tier by an identification and routing sub-process402.

The system100thus uses a star type architecture with any to any communication capability through a message exchange. Anywhere from 1 to M supply chain players in 1 to N supply chain tiers, each representing a role specific demand or supply business entity communicate with their suppliers and/or customers by posting messages to a message exchange, and periodically polling for and pulling from the message exchange any incoming mail from suppliers and/or customers. A specific supply chain player can only see messages addressed to their business entity.

It will be noted that while the message server106has a message que that contains snippets of demand and supply information, there is no queryable central data repository as is found in the centralized supply chain model30. Messages140flow through the message que on their way from the sender to the receiver. Messages140stay in the message que only until a receiver picks them up.

The typical collaboration dialogue used by the centralized model30or the loosely coupled model60entail a multi-item request followed by a multi-item response. That is, prior art models might in a single request ask a supplier to evaluate its ability to support a demand statement consisting of multiple demand items. And the supplier in turn provides a single response which covers their ability to supply all demand items in the request. Unlike the typical solution dialogue, the message140employed by the network based demand supply rationalization method200equates to a request to evaluate a support position for a single demand item. It is the carefully sequenced end to end evaluation of a series of single item message objects that allows the network base demand supply optimization method200to effect a coordinated inter entity, inter level priority driven squared set allocation of supply to a multi item demand statement.

From the foregoing it can be seen that the present invention provides an available to promise inventory allocation tool providing both the time-efficient closed-form optimal allocation solutions characteristic of centralized supply chain models as well as the cost and flexibility benefits of the loosely coupled supply chain models.