WO2000077666A2

WO2000077666A2 - System and method for promising delivery of configured products

Info

Publication number: WO2000077666A2
Application number: PCT/US2000/016095
Authority: WO
Inventors: Arshish C. Kapadia; Joseph L. Self
Original assignee: I2 Technologies, Inc.
Priority date: 1999-06-14
Filing date: 2000-06-12
Publication date: 2000-12-21
Also published as: AU5607500A; WO2000077666A8; TW480411B

Abstract

A system for committing to purchaser customized orders provides that only allowable configuration selections are presented to the user. A configuration engine is tightly coupled with an available to promise engine, which is accessed for component availability each time a set of selections is presented to the user. Only those components which will actually be available are presented for user selection, ensuring that a valid and available final configuration is assembled. If delivery dates are a constraint, only components which are actually available to promise by the desired delivery date are presented to the user as part of the selection set.

Description

System And Method For Promising Delivery Of Configured Products

Technical Field

The present invention relates generally to electronic computer systems, and more specifically to systems and methods for automatic configuration of orders to ensure availability.

Description of the Prior Art

With the significant and accelerating increases in digital interconnectivity and machine communications in the last decade, ordering of products from a manufacturer has undergone many changes. In some industries, a sale is no longer a matter of a salesman placing an order and hoping the manufacturing plant can meet the order requirements. Instead, it is necessary to match the manufacturing capability of the plant with orders entered into the system to improve response time and maximize system efficiency. In certain industries, one technique used by companies to distinguish themselves over their competition is to offer increased levels of customization of their products. For example, a computer manufacturer, often a systems level integrator of independently manufactured subsystems, can make available a wide variety of configuration options. This enables the purchaser to configure a custom system to meet his or her particular needs. However, allowing the purchaser this flexibility puts a tremendous burden on the manufacturer to ensure that all desired products and configurations are available, and available in a timely manner.

When a user customizes the configuration of his product, actual assembly of the product takes place after the order is entered. Examples of industries using this approach are the personal computer and automobile industries. Although some products are sold pre- configured, others are assembled to the customer's order. After the order is entered, the manufacturing facility must assemble the order as specified. This after order assembly requires that predicted delivery dates be provided to the customer at the time the order is entered. In recent years, to deal with this complex problem, powerful systems have been implemented to assist with order entry and custom product configuration. Products such as the RHYTHM system available from 12 Technologies, and similar products from other sources, have seen increasing acceptance as manufacturers strive to provide improved customer service. Among other features, these systems generally provide a configuration enαine to assist the Durchaser in defininq and customizinα her product. Once the product has been defined, an Available to Promise (ATP) engine ensures that all of the required components are available, and commits to a shipping date.

The configuration engine, also referred to as a configurator, contains a sometimes complex set of rules defining valid product configurations. Not all possible configurations of subsystems and components are allowed by the seller. For example, a company in the computer assembly industry can allow only selected combinations of processors, disk storage units, displays, and memory configurations. These limitations act as constraints on the selection of which components can be used to assemble the final product. Because even a relatively limited offering can give rise to a large number of possible component combinations, the logic required to perform the configuration function can be quite large and complex.

From the purchaser's perspective, an interface is provided to the configuration engine which enables component selections to be made. For example, the user can select a particular type of base computer system to be purchased. The configuration engine will then lead the purchaser through a series of selections to customize the final product as desired. Of course, the customer is entitled to select a predefined package, but it is often the case that one or more variations from the standard product is desired.

As each selection is made, it imposes additional constraints on the set of valid configurations. Thus, prior selections constrain the user in making later selections. For example, in the computer assembly context, purchaser selection of a laptop computer, as opposed to a desktop model, will influence the components which may be selected to go into the final product. For example, once a laptop has been selected, only displays which are compatible with that laptop may be selected in the future. The configuration engine maintains the relationships necessary to ensure that the purchaser selects from only valid component choices.

Once the purchaser has completed definition of a product, the configuration engine submits the order to the manufacturer, which may be represented to the configuration engine as an Available to Promise engine. The ATP engine confirms the availability of all of the components required to assemble the product, including the availability of sufficient manufacturing resources to assemble the components into the final product. Some of the components and resources may not be available until some time in the future. The ATP system then confirms the order back to the purchaser at the user interface, provides a delivery date, and commits the components and resources at the manufacturing level.

Sometimes, certain components are not available at all, or their time of availability is unknown. In this case, the purchaser receives notification that his desired product is not available. In other words, the combination selected by the purchaser may be valid, but currently unavailable due to component shortages.

In other cases, the purchaser receives a delivery date commitment which is later than desired. This can be due to shortages of certain components used in the ordered product, or unavailability of manufacturing facilities.

In either case, the purchaser is generally dissatisfied with the result. The purchaser then goes through the selection process again to try to fashion a final product which meets his needs and is available in an acceptable time frame. The process may take several tries before an acceptable order is entered, and accepted by the manufacturer. It would be desirable to provide an order entry system which allowed for purchaser defined product ordering, but which minimizes the occurrence of order rejection. It would further be desirable for the configuration system to ensure timely commitment to delivery of orders.

Summary of the Invention

Therefore, in accordance with the present invention, a system for committing to purchaser customized orders provides that only allowable and available configuration selections are presented to the user. A configuration engine is tightly coupled with an available to promise engine, which is accessed for component availability each time a set of selections is presented to the user. Only those components which will actually be available are presented for user selection, ensuring that a valid and available final configuration is assembled. If delivery dates are a constraint, only components which are actually available to promise by the desired delivery date are presented to the user as part of the selection set.

Brief Description of the Drawings

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

Figure 1 is a high level block diagram of an order entry system in accordance with the present invention;

Figure 2 is a flowchart illustrating operation of a preferred embodiment of the order entry system of the invention; and WO 00/77666 PCT/USOO/l 6095

- 4 -

Figure 3 is a more detailed block diagram illustrating additional features of the preferred order entry system.

Description of the Preferred Embodiment The present invention is useful in the context of order entry for industries which allow product customization by customers, but is not limited to such applications. The examples and description below, for purposes of illustration, assume that a user wishes to customize a single product, and that the product will be assembled, or assembly will be completed, only after an order is finally entered and committed. The customization process is assumed to allow a user to select items, or components, from lists of choices to provide the customized product. For each portion of the product which can be customized, one or more selections from a list will need to be made by the user.

In addition, the delivery dates for the customized product are assumed to depend to some degree on the customized options selected. Thus, selection of a different group of options may shorten or extend the delivery date for the product. If the delivery date must be set, some choices may not be available for the user to select.

As illustrated in Figure 1 , a purchaser enters an order through a user interface 10. The user interface 10 is connected to a configuration engine 12, also referred to as a configurator, which provides the intelligence to restrict the selections made by the user to a set defined in advance by the manufacturer. The configuration engine 12 includes logic implementing a set of rules and relations defining the allowable configurations of components which may be selected by the user to configure products sold by the manufacturer.

The configuration engine 12 is connected to an available to promise (ATP) engine 14. As known in the art, the ATP engine 14 includes a database which identifies all components and subsystems which are currently actually available, and the dates on which they can be shipped. Subsystems of components can be shipped only on the latest date all of the components which make up that subsystem are available. The ATP engine commits to dates on which the components and subsystems will be available to ship to the purchaser. In prior art systems, a completed order was submitted to the ATP engine 14 by the configuration engine 12. In the present invention, however, the configuration and ATP engines 12, 14 are much more tightly coupled than in prior art systems. In the preferred embodiment, a request is made to the ATP engine 14 immediately before a selection is presented to the user. The configuration engine 12 determines a set of items to be presented for selection accordino to its defined rules. Each of the items in the set is communicated to the ATP engine 14, which returns an indication of availability and a delivery date for each item to the configuration engine 12. The configuration engine 12, through the user interface 10, then presents to the user only those items which are actually available for selection, and the earliest delivery date on which all selections are actually available. In other words, an individual item may be available earlier, but the product is not available until the latest delivery date of the items which make up the product.

The term available does not necessarily mean that an item is currently in stock, but that it will be available by the time that it is needed. Thus, when the ATP engine indicates that a component will be available in two weeks, that component may not yet be physically present, but is expected to be no later than two weeks from the present time. The process of committing to product shipments can extend of many levels of manufacturing, so that the final assembly entity assumes availability of products which are currently several levels down the manufacturing chain. So long as all manufacturers are able to meet their commitments, the products will actually be there when needed. Communication with suppliers to keep the incoming product pipelines full is one of the functions of the ATP engine.

Once a selection is made by the user, the configuration engine 12 determines a next set of items to be presented for selection. The above process is repeated until the product is completely configured. Once a final product configuration is obtained, it is submitted to the ATP engine for a commitment of the order. Because each selection was made from a list of items known to be available, the user is constrained to enter only valid and available product configurations. The only circumstance in which a final order can be rejected is if one or more items become unavailable between the initial selection of that item and final order commitment, which is a relatively unlikely event.

Figure 2 is a high level flowchart giving more details of the process outlined above. The following description assumes that only a single product is being configured, but the same steps are used when multiple products are purchased in a single order.

Initially, the product to be purchased is selected by the user 20. The configuration engine contains sets of static configuration constraints for each product, and the appropriate static configuration is set up for the selected product. Unlike prior art systems, no static default selections are established for each item. Instead, defaults are preferably dynamically selected based upon an optimization function defined by the manufacturer and applied to the database of available items at run time. At any time, if the user wishes to accept the product, even if more choices can be made for some components, the user can end the configuration process and accept a complete product. If any additional constraints are to be applied to the WO 00/77666 PCT/USOO/l 6095

- 6 -

configuration, such as requiring a particular ship date, these are defined and entered 22 into the configuration engine for use in pruning future selections.

The configuration engine then determines a set of items to be presented to the user for selection 24. The initial set, and subsequent sets based upon earlier selections made by the user, are defined via constraints within the configuration engine in a manner known in the art. Before actually displaying the items and allowing the selection to be made, the ATP engine is queried to determine the actual availability of each of the items 26. This may be done by collecting all of the items into a group and making a single query, with the ATP engine returning a result data structure 28 containing an indication of availability and possible shipping date for each item. In practice, to reduce the number of queries to the ATP engine, an implementation can move some constraints from the ATP engine to the configuration engine, but the conceptual operation is unchanged. Constraints suitable for moving to the configuration engine are those for items which have no shared dependencies, (ie, those items not used in more than one subassembly) In the preferred embodiment, the act of querying the ATP engine for availability does not enter an order and commitment transaction. In other words, the items which are the subject of the query are not reserved or committed at the time of the inquiry, but are only committed later at the time of final order entry. This could result in a user defining a product which is a valid, available configuration when defined, but which becomes unavailable by the time the final order is entered for confirmation and commitment. However, this approach avoids the problems which can occur as a result of committing each component as it is selected, followed by uncommitting these components later if the configuration is changed or no final order is entered. Although not preferred, the latter approach can be used in certain circumstances if desired. In addition, most problems are avoided by a reasonably intelligent ATP engine. When the actual supply of a component runs low, or the expected availability of that component in the future becomes borderline or uncertain, the ATP engine can treat the situation as one in which the component is simply unavailable. Additionally, a high level of enquiries for a component indicates that orders will probably be placed against the components very soon, so that tracking such enquiries may indicate that a component should be indicated as unavailable even though the number of actual commitments has not depleted the supply. Good requirements planning will also minimize any problems.

After the query result is received from the ATP engine, a list of valid, available selections is presented 30 to the user. Typically, an indication is made to the user of the available shipping date for each selection. This allows the user to see the impact on delivery of decisions made during configuration. If the user defined a preferred shipping date as a constraint in step 22, this constraint is used to further prune the list of valid selections before presentation to the user. In other words, the configuration engine considers as unavailable any component which is only available after the required shipping date. This may mean that less configurations are available for the user than is the case with unrestricted dates, but the user can balance desired delivery dates against the possibility of more options to choose from.

The user then selects one of the available options from the list, which the configuration engine accepts 32 and uses to update the product configuration 34. The updated product configuration may impose additional constraints on later choices, and may also make additional choices available. For example, if a user is configuring a truck, selection of a larger engine may make future selections of tires and fuel tank available which would not be the case if a smaller engine were selected. If a selection will make additional selections necessary to completely define a product, additional default selections will be added to the configuration as well. As was the case with step 20, this ensures that a complete product configuration is always defined.

If the final user selection has not yet been made (step 36), the configuration engine determines the next set of items for selection 24 and repeats the process. Earlier selections modify the initial constraints as described above. Once the last selection has been made (step 36), or if at any time the user indicates that for the remaining selections the defaults are acceptable, a completed order for the product is submitted to the ATP engine 38. This submission is different from the previous enquiries for availability, in that order submission causes the ATP engine to commit the necessary components and resources required to assemble the product. If component or resource availability have changed during the configuration process, it is possible that the ATP engine may not be able to commit to the final order, or that the commit date will be later than previously determined. Because this is a relatively unlikely event, the preferred embodiment provides for no commitment until the final order is entered, rather than committing resources and components during the configuration process, which may have to be undone relatively more often.

At this time the process for configuring the product is complete. Of course, additional products may be configured in a single session, and orders may be withdrawn with the accompanying requirement for reversing the resource and component commitments previously made. These typical procedures are known in the art, and may easily be incorporated into the process of the invention. WO 00/77666 PCT/TJSOO/16095

- 8 -

Figure 3 illustrates additional details of the preferred coupling between the configuration engine 12 and the ATP engine 14. Several configuration options 50 are part of an option group 52. Each configuration option corresponds to an orderable item 54, which may have additional orderable options descending from it in a chain. These represent related items which must be checked to ensure availability, as described below. The option group 52 is a set of items available for selection according to the static rules of the configuration engine 12. The list of items presented to the user will come from this group 52. Once a group of configuration options is determined by the configuration engine 12 to be the set from which the user is to select next, the corresponding orderable items are communicated to an ATP server 56 through an asynchronous multiplexor 58. Although the ATP engine 14 is depicted as divided into several parts, the details of this division are dependent upon the particular implementation. Smaller applications can be implemented on a single piece of hardware, while very large applications will need to be spread across multiple machines in order to obtain reasonable response times. For purposes of illustration, Figure 3 shows ATP engine 14 as implemented on two separate servers 56, 57. Other configurations can be used as desired.

The request made of the first ATP server 56 is for availability of manufacturable items corresponding to the orderable item. An example of such a relationship would be a 4 gigabyte hard drive as an orderable item, with drives from two or more different manufacturers being manufacturable items corresponding to the same orderable item. If more than one manufacturable item can be used to satisfy a request for an orderable item, these are referred to as alternate manufacturable items.

Sometimes an orderable item will be a subassembly, which in turn is made up of various items and alternate items. The parts of the subassembly may or may not be separately orderable by the user, but in the context of parts to be assembled into an orderable item, they are not. For example, if a user selects a disk drive unit, several drives may be available to satisfy the request for an orderable item. In addition, different controllers may be available for use with the drive unit, and the controllers which can be used may be different for each drive. At the configuration item level, the user may order a disk drive, and any valid combination of drive units and controllers can be used to satisfy the request.

Figure 3 illustrates, in ATP server 56, three orderable items 54. One of these items can be satisfied by three alternative manufacturable items 60. One of the alternative manufacturable items 60 in turn may be satisfied by either generic manufacturable item 62, one of which may be satisfied by either manufacturable item 64. The tree of items which can be used to satisfy a reαuest for an orderable item 54 depends on which items are available to the manufacturer. Determining whether an orderable item is available is determined by traversing the tree to determine whether any set of components or alternatives which make up that orderable item are all available.

Once ATP server 56 has determined the availability of the various requested components, it returns this information, along with available delivery dates, to the configuration engine 12. The configuration engine 12 then compares the list of available items against any additional constraints, such as required product delivery dates, and presents a selection list to the user through the user interface as described above.

The above description appears to assume that each request to the ATP engine 14 includes availability of only the particular items to be presented to the user in the selection list immediately being prepared for presentation. This might be a suitable approach in some implementations, but the preferred embodiment uses a more complete approach to determining item availability. This approach requires that all related components, which may be required if an item is selected, to be checked for availability at the same time that an item is checked. This checking can be carried through a graph of items to ensure that, if an item is selected, all related items are also available and a valid configuration is possible. If the necessary related items are not available, the item is also marked as unavailable.

If the related items were not checked, an undesirable situation could arise in which a valid configuration could not be defined. In order to avoid this situation, it is preferred that the configuration engine 12 be aware of all constraint interrelationships between selectable items. Thus, if selection of an item requires certain minimum product capabilities, the availability of all of the items needed to supply these capabilities will be requested at the same time from the ATP engine 14. This will ensure that if a configuration is determined to be available and presented to the user, all required related subsystems are also available. This is the case even if some of the required related systems will be the object of a user selection at some later time.

As a simplified example, assume that a user separately selects a display subsystem and system memory for a computer product. If one of the orderable items for the display subsystem has a minimum requirement for system memory, the configuration engine 12 will confirm the availability of a sufficiently large system memory component before the display selection is presented to the user, even though the user will separately select system memory at a later time. This ensures that at least one appropriate system memory selection is available when that selection is to be made in the future. The earlier selection of the display will add a constraint to the later selection of system memory, and checking on availability of the required system memory at the earlier stage will ensure that at least one valid selection can be made at the time of the later selection.

Because of the manner in which the overall system is architected as described above, the order confirmation system of the present invention is easily adapted to available systems. Further, it can be used on a system which must be widely distributed. It is not necessary for the user interface 10, configuration engine 12, and ATP engine 14 to be located together because the data that is passed between them is minimal. Simple messages giving requests and results do not require very much to be communicated; the more difficult computations are encapsulated within each separate engine. The user interface can communicate with the configuration engine over a low bandwidth connection, such as a modem connection or a network such as the internet. This allows multiple remote users to configure products from a manufacturer over the internet or other communications system.

With a system such as the example described above, the user is always presented with selection choices which will result in a valid system, and one which will actually be available. Industries which can make efficient use of such systems will be recognized by those skilled in the art, and include, for example, customization of computer systems and customization of automobile purchases. Other industries which must match available resources with customer desires, such as airline scheduling, can also take advantage of systems of this type. With the improved customer service provided by limiting customer choices to always available, valid configurations, appropriate industries can enhance their customer service while improving operational efficiency.

While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.

Claims

1. A method for configuring products, comprising the steps of: presenting a series of item selection sets to a user through a user interface; for each presentation, determining a first set of valid item configurations; before presenting each item selection set to the user, searching information which identifies available items and determining which items from the first set are actually available; and during the presenting step, presenting to the user only item selection sets which are both valid item configurations and which are actually available.

2. The method of claim 1 , wherein the step of determining a first set of valid configurations comprises the steps of: prior to any selections being made by the user, defining and storing relationships between items in a product; and for each presentation, using the stored relationships to select a first set of valid item configurations.

3. The method of claim 1 , further comprising the steps of: after the presenting step, accepting a selection from the user of an item in the selection set; and applying the result of the user selection as a constraint to modify the step of determining the first set of valid item configurations for the remaining presentations.

4. The method of claim 1 , wherein the presenting step further includes presenting with each item of the selection set a date on which the product can be delivered if that item is selected.

5. The method of claim 1 , wherein the searching step comprises the steps of: searching a database of available items to determine which items in the first set are available; and associating with each such available item a date on which the item is available.

6. The method of claim 5, wherein the presenting step further includes presenting with each item of the selection set a date on which the product can be delivered if that item is selected.

7. The method of claim 1 , further comprising the steps of: after all of the item selection sets have been presented to the user and selections received therefrom, ordering an associated configured product from an available to promise engine; and committing the selected items for use in a configured product for the user.

8. A method for configuring products, each having a plurality of parts, in conjunction with a user, comprising the steps of: accepting from the user a set of constraints regarding configuration of the product; for a first part, determining a set of valid item configurations consistent with the configuration constraints; for each item in the set, determining whether such item is currently available within the constraints; presenting to the user a list of only those items in the set which are currently available; accepting a selection from the user choosing an item from the list; and for each of the remaining parts, performing the determining, presenting, and accepting steps, wherein the selections accepted from the user modify the configuration constraints for later selected parts.

9. The method of claim 8, wherein the set of constraints includes a required delivery date.

10. The method of claim 8, wherein the step of determining a set of valid item configurations comprises the steps of: determining a set of items which may be presented to the user in accordance with predefined rules regarding product configuration; and for each item in the set, .determining an associated second set of dependent items which will be required to be available if that item is selected by the user;

wherein, in the step of determining whether each item in the set is currently available, an item in the set of valid item configurations is only considered to be available if the dependent items in the associated second set are also available.

11. The method of claim 8, wherein the presenting step further includes presenting with each item of the selection set a date on which the product can be delivered if that item is selected.

12. The method of claim 8, further comprising the steps of: after all of the item selection sets have been presented to the user and selections received therefrom, ordering an associated configured product from an available to promise engine; and committing the selected items for use in a configured product for the user.

13. A method for configuring products, comprising the steps of: defining a set of constraints for the product, including a set of selection decisions to be made by the user, and a set of items to be selected from for each decision; accepting a constraint from a user defining a user constraint; for a first selection decision to be made by the user, determining which items of the corresponding set are currently available; presenting to the user a list of only currently available items within the set; accepting from the user a selection of an item, wherein the selected item becomes an additional constraint on future selections; repeating the determining, accepting, and accepting steps for the remaining selection decisions; and providing a completed product configuration which includes the items selected by the user.

14. The method of claim 13, wherein the presenting step further includes presenting with each item of the presented list a date on which the product can be delivered if that item is selected.

15. The method of claim 13, further comprising the steps of: after all of the selection decisions have been made by the user, ordering an associated configured product; and committing the selected items for use in a configured product for the user.

16. A system for configuring products, comprising: a user interface for displaying lists of items to a user and accepting selections from the user; a configuration engine in communication with the user interface, the configuration engine containing definitions of relationships between items in a product, wherein the configuration engine determines selections to be made by the user and defines sets of items which are valid selections; an available to promise engine in communication with the configuration engine, wherein the available to promise engine, in response to a query from the configuration engine, returns an indication of item availability; and wherein the configuration engine queries the available to promise engine for each item in a defined set before communicating the items to the user interface, and selects for communication to the user interface only items which are indicated as available by the available to promise engine.

17. The system of claim 16, wherein the available to promise engine contains, for each item, an associated delivery date; and wherein the user interface displays the associated delivery date for each item on the list.