WO2005062771A2 - System and method for supply chain management to allow intelligent shipment scheduling that accounts for shortages and delays - Google Patents

System and method for supply chain management to allow intelligent shipment scheduling that accounts for shortages and delays Download PDF

Info

Publication number
WO2005062771A2
WO2005062771A2 PCT/US2004/042311 US2004042311W WO2005062771A2 WO 2005062771 A2 WO2005062771 A2 WO 2005062771A2 US 2004042311 W US2004042311 W US 2004042311W WO 2005062771 A2 WO2005062771 A2 WO 2005062771A2
Authority
WO
WIPO (PCT)
Prior art keywords
supply
date
order
demand
issued
Prior art date
Application number
PCT/US2004/042311
Other languages
French (fr)
Other versions
WO2005062771A3 (en
Inventor
Sujit Kumar Saraf
Original Assignee
Valdero Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Valdero Corporation filed Critical Valdero Corporation
Publication of WO2005062771A2 publication Critical patent/WO2005062771A2/en
Publication of WO2005062771A3 publication Critical patent/WO2005062771A3/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • Businesses may depend on projections of such impacts to make informed decisions in a short amount of time. They may also be critical to a business 's competitive edge. This becomes important as manufacturers are now outsourcing more and more products, further depending on outside business partners. When certain supplies or demands of products or individual components change, it affects inventory, product releases and other business-critical operations. To complicate matters further, these business partners often exchange information electronically on different and incompatible formats. As a result, many businesses resolve this problem by actually exchanging paper documents among themselves. This of course seems evident in light of modern day advancements in computer technology. However, most businesses that focus on producing products will not easily change their business practices at the administration level in fear of inhibiting their product flow. In order to gain acceptance by businessmen, any new method of exchanging data needs to be easily adaptable.
  • the data loading and mining tools typically operate in a relational database, which requires some type of dynamic catalog to operate. In order to combine a reporting module with these operations, it must be integrated to use such a catalog. Unfortunately, integration of these entities is usually an afterthought. As a result, integration is very complicated, requiring special software code to build relationships among the modules. The end result is usually an inflexible custom application that is developed for a particular use, requiring ongoing development and maintenance at the database level. As a result, end users must rely on highly trained individuals to maintain such systems on site. Therefore, there exists a need for a solution that can centralize information and allow access to certain supply chain information in an organized and useful manner. Such a solution would obviate the need for first line support at the user's site. As discussed below, the invention accomplishes this in a unique and elegant manner.
  • Figure 1 illustrates system process configured according to the invention is illustrated in a diagrammatic manner, where the method 100 is configured to establish orders in a supply chain managed according to the invention.
  • Figure 2 a flow chart 200 illustrates the operation of a system according to the invention from a user's point of view.
  • Figure 3 a system flow diagram 300 is illustrated.
  • Figure 4 illustrates a user input page.
  • Figures 5 and 6 input parameters and their related criteria are illustrated in table form.
  • Figure 7 is a user interface for a user to review demand dates.
  • Figure 8 this webpage view shows all the ship sets and the details associated with them.
  • demand quantity is illustrated.
  • Figure 10 a user interface is illustrated.
  • Figure 11 a user interface is shown for choosing supply.
  • Figure 12 a user interface is shown for observing work in progress.
  • FIG 13 a chart illustrating parameters for choosing by the user is illustrated.
  • Figure 14 illustrates how parameters in Figure 13 can be modified.
  • a user interface is illustrated for selecting parameters.
  • user interface for confirming selecting parameters is illustrated.
  • Figure 17 a sample scenario is illustrated.
  • an Order Summary Drilldown Overview is illustrated.
  • a drilldown view is illustrated.
  • this view basically details all those supply that have an action "None" associated with them.
  • a drill down view is illustrated.
  • Figure 23 a parts summary view is illustrated.
  • Parts Summary Drilldown Overview is illustrated.
  • drill down details are illustrated.
  • this view is similar to the previous view of Figure 25.
  • Figure 27 the various columns in this view are explained.
  • Figure 28 illustrates the manner in which a typical company operates.
  • a chart is shown of a sample for creating weighted values for Ranking Strategies.
  • Figure 30 and 31 illustrates the user has the ability to update or delete the ranking strategies.
  • Figure 32 a WIP page is illustrated.
  • Figure 33 illustrates Buildable Supply Problem Supply and STO Functionality.
  • Figures 34-36 illustrate process steps.
  • Figures 37-39 illustrate process steps.
  • Figure 40 illustrates a flow diagram of some scenarios.
  • a system and method configured to manage supply chain information according to detailed demand and supply criteria over a broad time line.
  • the invention resolves an ongoing problem that supply chain management systems face, where inventory visibility is laclcing, and addresses specific problems of shortages and delays. This is primarily a result of the difficultly of managing ever changing inventories of incoming supplies and lead times of product units and sub-units, such as component parts.
  • the invention provides a prioritization module configured to prioritize customer product orders according to customer criteria, and business policy.
  • the prioritization is set according to a Supply and Demand Matching (SDM) algorithm that, when executed, calculates predetermined customer criteria and accounts for predetermined relative priorities based on historical customer information, such as past, current and projected customer product demand.
  • SDM Supply and Demand Matching
  • An assembly planning module establishes a unit (such as a finished product) assembly schedule according to scheduled availability of sub-units (such as component parts).
  • a scenario module is configured to generate a unit delivery scenario according to customer priority as determined by the prioritization module.
  • An assembly schedule is then generated as determined by the assembly planning module, where the scenario module defines a unit delivery scenario that provides a delivery schedule.
  • This delivery schedule may enable production of partial shipments of available units at scheduled times based on scheduled availability of sub-units, when complete shipments are not available at particular times.
  • the delivery schedule accounts for various constraints including manufacturing lead times and other criteria. Other criteria may include capacity constraints, whether they are constrained by the capacity of the manufacturer or other source or supplier. The criteria may also include transport time constraints, such as between different suppliers or to customers. Criteria may further include constraints imposed by
  • ECO Engineering Change Orders
  • Criteria can be established, and business rules can be set to prioritize orders. For example, if you have a large order for a large customer, you might want to put them out front in the delivery schedule.
  • the system can also rank strategies according to criteria.
  • a producer can allow prioritization based on a host of criteria.
  • Conventional systems allow prioritization based on some well-known order attributes, such as scheduled ship date, or order revenue.
  • a system configured according to the invention can allow, for example, prioritization of customers themselves, prioritization by margin, by channel, by type of demand, or other criteria and combinations of criteria.
  • the invention enables a user to use that criterion for prioritization.
  • a user can operate a tool to run a scenario.
  • a user can then get exceptions and recommendations in a scenario.
  • the scenario operation is fulfillment based, allowing a user to respond to changes to supply and demand on the fly.
  • the invention would further enable a system to recommend new purchase orders, new work orders, and new stock transfer orders.
  • a system configured according to the invention is based on "fulfillment" of orders, rather than simply "planning" of orders.
  • the invention further provides the ability to establish a weighted score, an overall numerical score for each demand (whether a sales order or forecast), that allows the system to prioritize that demand. It may be computed on the basis of many criteria specified by the customer.
  • the SDM matching algorithm considers the weighted score, in that it allocates supply to demand in order - demands with higher weighted scores are met first. Depending on properties of demand and supply, the SDM algorithm handles shortages and delays differently. For example, if new supply may be issued for a part, SDM issues new supply.
  • step 102 an order is received, and it has a weighted score established in step 104.
  • the priority module 106 establishes priority criteria according to customer priorities, which are established by the user or other entity, and other criteria, including capacity, timing, ECOs and other criteria.
  • the supply and demand are assessed according to the order and related information in step 108. It is determined whether a new supply is authorized in step 110. If it is, a new supply is issued in step 112. If not, then the order is filled by existing supplies or by other means. If the order is not allowed to issue new supply and it requires new supply, then it can be shipped partially, or not at all, but cannot be shipped fully. Next, it is determined whether partial shipments are authorized in step 114.
  • step 116 If they are, then the supply and demand are assessed in step 116 in light of partial shipments, a partial shipment ichedule is generated in step 118, and the partial shipping is effected in step 120. If partial shipments are not authorized, then the system establishes that the entire order is to be shipped in step 122. Next, it is determined whether the shipment is to be done on time only in step 124. If yes, then it is determined whether the shipment is scheduled on time in step 126. If it is not on time, then the order is cancelled in step 128. If it is on tome, then the shipping order is completed in step 130.
  • the invention is directed to primarily two problems, shortages and delays. The definitions of those are provided below.
  • a shortage is where the allocation of demand results in a shortage problem if there is a lack of components. (Only buy parts). It is important to note in this definition is that this shortage could occur within lead-time or outside the lead- time of the product. Thus, an order would be considered short simply if there are not enough sub-components available (on/hand) or on order (WTPs, POs, Intransit) to build the end-item associated with the order. It is quite possible that the sub-component could be procured to meet the order on its schedule date. However, irrespective of this, the order may still be defined as a short order. Shortage Policies A system configured according to the invention would have policies established that determine the behavior of the SDM algorithm when they encounter a shortage problem.
  • the algorithm creates a new Supply to fulfill the order and recommends the same.
  • the algorithm does not issue new supply and thereby fulfills the order partially to the extent of the available supply. Partial shipping may applicable only when there is a single line ship set. When, there are multiple lines that are defined as part of the ship set, partial will result in no allocation for the ship set.
  • SDM will allocate supply to only those orders that can be completely fulfilled given the available supply. The decisions are based on the available supply and not based on potential new supply.
  • a delay may be defined as an order that cannot be delivered before the schedule date of the order, given the available supply (current scheduled delivery date) and the new recommended supply (only leaf node new PO's).
  • embodiments may invoke two restrictions.
  • the allocation mechanism may not issue any new recommended supply if existing supply can meet the order. In certain cases, it is quite possible that new supply could satisfy the order on time as opposed to existing supply.
  • one of the key elements of SDM is that excess supply should not be recommended. Instead expedite messages on pre- planned supply should be recommended.
  • Second, a new supply recommendation is based on the policies that are chosen in the case of shortage policies (Shortage). Thus, only when the user chooses "Create New Supply" will supply be recommended.
  • a system that has policies that determine the behavior of the SDM algorithm when they encounter a delay problem.
  • the algorithm still allocates supply and provides re-conciliation messages on solving the delay problem. (Through Best Dates).
  • the SDM mechanism encounters a delay problem while allocating supply; the algorithm allocates supply and fulfills the order partially. Thus, the algorithm does not delay the partially allocated order.
  • Ship only on-time Orders In the case of requests to ship only on-time orders, when there is a delay problem, SDM will allocate supply to only those orders that can be completely fulfilled on time given the available supply state.
  • Shortage and Delay Policies in Conjunction
  • Shortage and Delay are two independent problems. Hence, these two have different policies to solve each problem.
  • UI Flow The embodiment described herein is illustrated from a user's point of view, described and illustrated in terms of UI Flow for the application. The embodiment description begins with a high-level flow model of the SDM Module. Following that, each box (Corresponding page in the SDM Module) is detailed out.
  • a flow chart 200 illustrates the operation of a system according to the invention from a user's point of view.
  • the system receives the user's input.
  • the demand criteria are established in step 204.
  • step 206 demand is chosen in step 206, a user may edit the demand dates in step 208, then rank demand terms in step 210, edit the demand quantity in step 212, then create orders in step 214.
  • step 216 the supply is established; where the supply criteria are established in step 218 and partial shipments, if authorized, are established in step 220. Once all of this data is received, then the supply and demand parameters are established in step 218. The user can confirm the criteria in step 220, and store the results in step 222.
  • a system flow diagram 300 is illustrated. The user input is received in location 302 at stage 1. In stage 2, the demand system 304 allows a user to choose demand the demand.
  • the operations module 306 allows a user to establish an order and its priority.
  • stage 3 the system allows a user to view and edit demand dates.
  • stage 4 a user can view and edit the supply.
  • stage 5 a user can select parameters for the order.
  • stage 6 a user can confirm the order.
  • the allocate criteria, results and the supply and demand details are then stored in the user input storage 308.
  • a user is enabled to constrain the demand for consideration in the allocation mechanism.
  • the user can pick only those ship sets/orders of interest. This will enable the user to contain the scope/analysis of the allocation mechanism to only those demand signals that he/she is interested in.
  • SO Slotting Criteria This parameter works in conjunction with the parameter SO Date Range. There are three possible date ranges for selecting SO's: CRD, Promise Dates and Schedule Dates. Hence, when a user chooses the selection " CRD" for the "SO slotting criteria" and chooses an SO Date Range, the application will return all SO's whose CRD lies in the date range specified.
  • Number of Top Orders This parameter limits the number of orders that are considered. This parameter works in conjunction with the parameter "Ranking Strategy”. The Ranking strategy ranks the selected orders/ship sets in a particular priority sequence. The number of Top Orders picks up the "n" number of ship sets/orders starting from the top ranked and returns them for consideration for the allocation mechanism.
  • Ranking Strategy Through a pre-defined set of rules, (Described in the Ranking Strategy section), the user will be able to prioritize the demand based on some attributes of the demand. For example, the user can prioritize demand in the order of their margins. This will become important because supply will be allocated to demand only in that fashion. This ensures that in the case of a shortage, the prioritized orders are not starved of supply. This forms the basis of the SDM Feature.
  • Parameters Choosing Demand Figure 4 illustrates a user input page. Referring to Figures 5 and 6, input parameters and their related criteria are illustrated in table form.
  • Figure 7 is a user interface for a user to review demand dates. Referring to criteria marked with a "*", these parameters are dependent parameters on the parameter "demand type”.
  • this webpage view shows all the ship sets and the details associated with them. These details include: • Original Rank - This is the rank that has been computed for the demand element. The user though has the flexibility to change individual ranks and re-prioritize on an exception basis with the help of the what-if capability • New Rank - This is a what-if rank that the user can use to over-ride the current rank • Demand Type - This is the demand type for the demand element • Demand quantity, Figure 9.
  • Order-Ship set / Forecast - This is the identifier for the demand element. This basically provides the identifier for the forecast and the ship set. For the ship set, the identifier is the "Order.Shipset-No". A link is provided from each of these identifiers to be able to view and edit the line details (Qty of the lines).
  • Order Type - This is the Order type for the ship set • Customer - Customer for the ship set / forecast • Order Status - Status for the Order. In the case of forecasts, this will be blank. This will be picked up from the ship set-status in dt_sales_order_shipset.
  • Original Revenue - This is the original revenue of the Ship set / Sales Order.
  • This pop-up can be accessed from the icon "i" next to the rank of each ship set / forecast.
  • This provides the details behind the computation of the score that is used to rank the demand elements. The higher score demand is ranked higher than the lower score demand.
  • the logic for the computation of the score is provided in a subsequent section on ranking strategy.
  • This picture is for the weighted strategy. (The order-by strategy will have fewer columns.2B - View and Edit Demand Qty
  • the view can be accessed from the "view and edit demand dates" view by clicking on the Order: ship set / Forecast field. This view displays the lines and the details of the lines belonging to the selected ship set. The various details selected in Figure 9 are: • Line - The Line number is displayed here. • Part - This displays the name of the part.
  • a user interface is illustrated for selecting parameters.
  • user interface for confirming selecting parameters is illustrated.
  • a sample scenario is illustrated.
  • the input parameters are the following: 1) Demand Type - This is the demand type associated with the demand element 2) Order Type - This is the order type associated with the demand element 3) Order Status - This is the status of the demand type 4) Analysis name - This refers to the simulation name that was run. We should ensure that we don't show other types of Simulations here.
  • this definition is configurable based on three system level-parameters - Short for Make Part, Short for Buy Part and Short for Transfer Part. Hence, for example, it is possible to define shortage only when you have a new PO / STO recommendation (buy / transferred). However, an order that contains a new WIP need not be identified as short if the system parameter associated with "short for a make part" is turned off. Hence, in our current model, we will have three system level parameters each for make / buy / transfer that can be turned off or on to define shortage in a configurable manner. Note, that this definition of short is different from the shortage definition (only buy), used in the inputs to make the Allocation Shortage Policy Decisions. This condition would happen when the user selects any shortage option.
  • Partial - An Order.Shipset is considered partially allocated if the end-assembly built is lesser than the required quantity. It should be noted that a partial condition does not have anything to do with the scheduled date. Partial simply implies that the allocation is partial. It could be before the scheduled date or later. A partial is caused only when the user chooses either "ship partial” on the delay policy or "ship partial” on the shortage policy. No Allocation - An Order.Shipset is reported with "No Allocation” if no material has been allocated to the order. A "No Allocation” is caused only when the user chooses either "ship only complete” on the delay policy or "ship only complete” on the shortage policy.
  • Short and Delay - An Order could be both short and delayed if in addition to being short, the end item is also delayed beyond its scheduled date. It should be noted that it is not necessary that the short components cause a delay. A delay could be caused either because of the new components or due to an existing supply source. This problem would be reported only if the user had chosen "Create New Supply” for the Shortage Policy and "Reconcile Delayed Policy” for the Delay Policy Delay and Partial - An Order.Shipset is considered partially allocated if the end- assembly built is lesser than the required quantity. In addition, this partially allocated Order.Shipset is also delayed beyond its schedule date. This problem would be reported only if the user had chosen "Partial" for the Shortage Policy and "Reconcile Delayed Policy" for
  • the available date is the date on which the ship set / forecast will be available given the current state of supply.
  • the available dates are simply defined as system dates, in- transit dates and PO dates respectively.
  • the available date at this level is constructed with the feasible available dates.
  • the available date would be different from the required date only if the user chose "Reconcile Delay" as the delay policy. Else, partial allocation or no allocation would result in the available date and the required date being the same. Shortage Policies have no bearing on the available date. • Best Date - There are two possible streams of actions that the Allocation mechanism suggests in the case of a delay. One set of recommendations is on the supply side (Best Date based) and the other recommendation set is on the demand side (Available Date based). The best date is the date on which the ship set / forecast can be allocated if the user chooses the component level pull-in and push-out recommendations wherever applicable. Essentially, the system tries to pull-in supply if it encounters a delay.
  • Line Number - This indicates the line number Customer - This is the customer for the order Order Type - This is the order type for the order Demand Type - This is the demand type for the order Held For - This will be the Site for which the sales Order is Originally Held for. Order Site - This will be the demanding site Supply Site - This will be the supplying site Parts - This is the end-item assembly name of the line • Part Description - This is the description associated with the part Scheduled Ship Date - This is the scheduled ship-date for the order. At the line level, the scheduled ship date is the same as the order level. This should be picked up from the schedule_ship_date in ft_sales or dt_sales_order_shipset?
  • the forecast-date (start or end-date of the period based on what is populated in forecast_ft will be used) Available Date -There are two possible streams of actions that the Allocation mechanism suggests in the case of a delay.
  • One set of recommendations is on the supply side (Best Date based) and the other recommendation set is on the demand side (Available Date based).
  • the available date is the date on which the individual line will be available given the current state of supply. Theoretically, the available date of all components could be built up to provide the available date at this level. There is just one caveat to the calculation of available dates.
  • the available dates are simply defined as system dates, in-transit dates and PO dates respectively.
  • the available date at this level is constructed with the feasible available dates.
  • the available date would be different from the required date only if the user chose "Reconcile Delay" as the delay policy. Else, partial allocation or no allocation would result in the available date and the required date being the same. Shortage Policies have no bearing on the available date.
  • the best date is the date on which the line can be allocated if the user chooses the component level pull-in and push-out recommendations wherever applicable. Essentially, the system tries to pull-in supply if it encounters a delay. This is reflected through the best date at the component level. It should be noted that the system recommends a pull-in only to the extent feasible based on lead-time considerations. Push-outs are recommended by the system in the case of STO's and WIP's based on infeasibility. This will be explained in greater detail in the section on WIP's and STO's.
  • the best date of all components could be built up to provide the best date at this level. Also, it should be noted that the best date would be different from the required date only if the user chose "Reconcile Delay" as the delay policy. Else, partial allocation or no allocation would result in the best date and the required date being the same. Shortage Policies have no bearing on the best date. There is only one reason why the system would compute best date, different from the available date at the component level: Delay Resolution - In the event that the available date > required date, the system would try to provide a best date so that supply can be pulled-in. However, it should be noted that the best date recommendation would honor lead-times. It should be noted that best dates are not computed if there exists no delay.
  • Delay is the number of days the order has been delayed. This can be calculated as "Min (0, Available Date - Schedule Date)".
  • Requested Quantity - This is the demand quantity used while allocating this demand. This is carried forward from the "Allocation Quantity" in the inputs. Allocated Quantity - This represents that portion of the requested quantity for which supply was allocated. This could be different from the requested quantity only if the user chose "Partial” / "Ship Only Complete” on the Shortage Policy or "Partial / Ship Only Complete” on the delay policy.
  • Drill to Problem Parts Referring to Figure 20, this drilldown view essentially brings up the details of the supply that were used in the allocation of the selected Order: Ship set / Forecast. In addition, this view shows only those supplies that have an action that is not of the type "None" (Explained later) associated with it. All supply that has an action type of "None" gets
  • Parts - This provides the name of the part associated with the supply Part Description - This is the description associated with the part Within Lead Time - This indicates if the delay problem (if it is a delay problem) can be solved by the recommendation. This flag is hence set to Y if the best date is earlier than the required date. Else it is set to N Action - These are the set of supply that has a required set of actions associated with them. The various types of actions are as follows: New - This action is recommended if there is a new recommended supply. This could be a new PO, a new STO or a new WIP, depending on whether the recommendation is provided for a buy, transfer or a make part.
  • WIP On-Hand
  • WIP-Requirement (Refers to the issued qty against the WLP), PO, STO, ASN, NEWWIP, NEWPO, NEWSTO, or other supply type.
  • Held at - This is the site where the supply is Held at or received at (for PO's / STO's /
  • Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO / STO / ASN). For all other supply sources, this should be N / A Required Date - This is the date on which the supply is required to ensure that this order is delivered on time. The required date at each level is computed by blowing down from the scheduled date at the order: ship set / forecast level.
  • Available Date - This is the date on which the supply is available given the current state. (This is derived from the input dates associated with the supply. Theoretically, the available date of all components could be used to provide the available date at the order: ship set / forecast level. There is just one caveat to the calculation of available dates. In the case of on-hand, In-Transit and PO as supply, the available dates are simply defined as system dates, in-transit dates and PO dates respectively. However, in the case of a WIP and an STO, the available date at this level is constructed with the feasible available dates. Feasible Available Date - This would be different in the case of only an STO / WIP based on feasibility.
  • a feasible available date would be computed. This would be based on the supply availability of the lower requirements. Details on this computation are provided in the WIP / STO sections. In all other supply types, the feasible available date would be equal to the available date. Best Date - This is the date on which supply can be best procured. The best date at the component levels could all be built up to construct the best date at the order: ship set / forecast level.
  • Allocated Quantity This is the quantity of the supply that is allocated to the order: ship set / forecast.
  • Past Due Supply - This will be a flag that will be set to Y / N depending on whether the supply is past due or contains any past due supply (for a WIP that contains a past due PO). Essentially, any supply, ex. PO that has a Schedule Date prior to the system date is rolled forward to the system date in the SDM mechanism as available supply.
  • Lead Time - This is the lead-time required for that supply. This is primarily the lead- time that is used in SDM. For a make part, this is manufacturing lead-time. This should be found in the PCB. For a buy part, this is procurement lead-time and again found in PCB. For a transfer part, this is the transfer lead-time Drill to Buildable Supply Referring to Figure 21, this view basically details all those supply that have an action "None" associated with them. Essentially, what this means is that this supply does not cause any problem to the order and need not be bothered with w.r.t allocation to these orders. The various field are explained below.
  • WIP On-Hand
  • WIP -Requirement (Refers to the issued qty against the WIP), PO, STO, ASN, or other type.
  • Held at - This is the site where the supply is Held at or received at (for PO's / STO's / ASN) as applicable.
  • Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO /
  • the available date of all components could be used to provide the available date at the order: ship set / forecast level.
  • the available dates are simply defined as system dates, in-transit dates and PO dates respectively.
  • Supply Quantity This is the quantity associated with the supply-id. This is the whole quantity. This is derived from the inputs and the details specific to the computation for each supply type can be found in the section "View and Edit Supply Details".
  • Allocated Quantity This is the quantity of the supply that is allocated to the order: ship set / forecast.
  • Past Due Supply - This will be a flag that will be set to Y / N depending on whether the supply is past due or contains any past due supply (for a WIP that contains a past due PO). Essentially, any supply, ex. PO that has a Schedule Date prior to the system date is rolled forward to the system date in the SDM mechanism as available supply. Although, this is a valid assumption, the user still wants to identify this dubious supply. Hence, this flag will help determine this.
  • Scenario 2 Parts Summary This view is an alternate view of looking at the results from the allocation. This basically enables a commodity manager to look at all components aggregated across all Order Allocations.
  • a drill down view is illustrated of a first level view is a view that provides the user the aggregate view of all components at the part / action / supply-type / held-at / supply-site level. This means that all unique combinations of the above dimensions will be represented as unique rows.
  • the second level drilldown- view provides the user the ability to look at all the supply-ids of those parts that have the parent dimensional combinations. Essentially, when drilling down all dimensions in the parent view are passed. In any view, the uniqueness of a row is determined by the combination of dimensions defined in the view.
  • the third drilldown takes the user to the list of orders that have the chosen supply id in their allocation.
  • the fourth level drilldowns are similar to the drilldowns in the order summary. Parameters - Input The input parameters for this will be the following:
  • Allocation Name This refers to the name of the SDM Simulation. We should not show any other type of simulation in this drop-box.
  • Product families - This refers to the product family of the components and assemblies for the end-assembly. This includes the product family of the end-assembly too 3)
  • Commodity codes - This refers to the commodity codes of the components and assemblies for the end-assembly. This includes the commodity codes of the end-assembly too 4)
  • Parts This is the parts (component / assembly / end assembly) that the user wants to see 5)
  • Part Type - Parts could be either make / buy / transfer parts 6)
  • Held at - This is the site at which the supply is held-at. (Received at) if it is a
  • Parts Summary View Referring to Figure 23, a parts summary view is illustrated. As explained in the above section, the first level view is a view that provides the user the aggregate view of all components at the part / action / supply-type / held-at / supply-site level. This means that all unique combinations of the above dimensions will be represented as unique rows. The description of the various columns is presented below. Parts provide the name of the part associated with the supply.
  • Part Description is a description identifier for the part.
  • Action defines the action associated with the part. New - This action is recommended if there is a new recommended supply. This could be a new PO, a new STO or a new WIP, depending on whether the recommendation is provided for a buy, transfer or a make part. This action is taken to solve a shortage problem (Make, Buy and Transfer Parts).
  • Part Type - A Part could be either a make, buy or a transfer part and this property is defined in PCB in addition to the appropriate linkages in BOM / BOD tables. Care should be noted that this attribute is fed consistent with the BOM / BOD table.
  • Supply Type - This column indicates the various supply types associated with the supply. They could be one of the following, WIP, On-Hand, WIP-Requirement.
  • Allocated Quantity This is the quantity of the supply that is allocated to the order: ship set / forecast.
  • Lead Time - This is the lead-time required for that part. This is primarily the lead- time that is used in SDM. For a make part, this is manufacturing lead-time. This should be found in the PCB.
  • the drill down structure is pictorially represented in Figure 24.
  • the first level view is a view that provides the user the aggregate view of all components at the part / action / supply-type / held-at / supply-site level. This means that all unique combinations of the above dimensions will be represented as unique rows.
  • the second level drilldown- view provides the user the ability to look at all the supply-ids of those parts that have the parent dimensional combinations. Essentially, when drilling down all dimensions in the parent view are passed. In any view, the uniqueness of a row is determined by the combination of dimensions defined in the view.
  • the third drilldown takes the user to the list of orders that have the chosen supply id in their allocation.
  • the fourth level drilldowns are similar to the drilldowns in the order summary. Dimensions Passing - In all these drilldowns all the dimensions in the parent view are passed down to the child view. It should be noted though that the best-date at the order-level view and the best date at the part-level views should not be mapped. Similarly, the other-dates.
  • Supply Type - This column indicates the various supply types associated with the supply. See above. Held at - This is the site where the supply is Held at or received at (for PO's / STO's
  • Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO / STO / ASN). For all other supply sources, this should be N / A.
  • Earliest Required Date - This is the date on which the supply is required to ensure that all the orders to which it has been allocated to is delivered on time.
  • Available Date - This is the date on which the supply is available given the current state. (This is derived from the input dates associated with the supply. Feasible Available Date - This would be different in the case of only an STO / WIP based on feasibility.
  • a feasible available date would be computed. This would be based on the supply availability of the lower requirements. Details on this computation are provided in the WIP / STO sections. In all other supply types, the feasible available date would be equal to the available date. Best Date - This is the date on which supply can be best procured. If the supply is broken-up, (for example if a PO is split (based on splittable flag, explained later), there could be multiple instances / rows of the same Supply-id.
  • Allocated Quantity This is the quantity of the supply that is allocated to the order: ship set / forecast, Revenue Impact - This is the sum of the revenue associated with all the unique orders to which this row combination (dimension combinations) has been allocated.
  • Drill to Affected Orders This drilldown will take the user to the same view as the problem order summary view. However, when we drill to this view, the list of orders that would come up would be the list of impacted orders due to the relevant supply id. For each of these order.shipset, three drilldown similar to the previous scenario will exist. Scenario 3 - Supply Details Referring to Figure 26, this view is similar to the previous view. However, this view directly goes to the supply details level.
  • the drilldown structure from there on and the views would however be similar to the drilldown structure in the previous views. However, the initial view would be different from the view provided in the previous view.
  • the first level view provides the user the ability to look at all the supply-ids that are used in the allocation. In any view, the uniqueness of a row is determined by the combination of dimensions defined in the view.
  • the second-level drilldown view takes the user to the list of orders that have the chosen (supply id, action and supply type) in their allocation. (Dimensions that should be passed)
  • the third-level drilldowns are similar to the drilldowns in the order summary. The input parameters are exactly similar to the ones in the previous view.
  • Allocation Name This refers to the name of the SDM Simulation. We should not show any other type of simulation in this drop-box.
  • Product families - This refers to the product family of the components and assemblies for the end-assembly. This includes the product family of the end-assembly too 3)
  • Commodity codes This refers to the commodity codes of the components and assemblies for the end-assembly.
  • Parts - This is the parts (component / assembly / end assembly) that the user wants to see 5) Part Type - Parts could be either make / buy / transfer parts 6) Supply Type - This indicates what is the type of Supply (WIP / PO etc.) 7) Held at - This is the site at which the supply is held-at. (Received at) if it is a PO / STO.
  • Start Date & End Date This is start date and end date (based on the original available date of the supply ) Note: Although the user has already chosen their input criteria in the allocation, this parameter constraint allows the user to look at only the outputs that he/she is interested in for one particular analysis. It is quite possible that different users (ex. Commodity Managers), looking at their own portfolio of Supply would like to see only those supplies that they manage. Referring to Figure 27, the various columns in this view are explained. It should be noted that this view is fundamentally different from the part level views that can be drilled down from the order summary view because, this does not represent supply specific to a particular order. Supply Id - This details the id associated with the supply.
  • Best Date This is the date on which supply can be best procured. If the supply is broken-up, (for example if a PO is split (based on splittable flag, explained later), there could be multiple instances / rows of the same Supply-id.
  • Delay Resolution In the event that the available date > required date, the system would try to provide a best date so that supply can be pulled-in. However, it should be noted that the best date recommendation would honor lead-times. It should be noted that best dates are not computed if there exists no delay. In other words, the system would never try to expedite if the available state of supply can meet the order on time. (Even if the available date has some slack).
  • Supply Quantity This is the quantity associated with the supply-id. This is the whole quantity. This is derived from the inputs and the details specific to the computation for each supply type can be found in the section "View and Edit Supply Details”.
  • Allocated Quantity This is the quantity of the supply that is allocated to the order: ship set / forecast.
  • Revenue Impact This is the sum of the revenue associated with all the unique orders to which this row combination (dimension combinations) has been allocated.
  • Order Ship set Number - This is the Order Ship set Number where the supply is used Line Number - This is the line number where the supply is used Line Part Name - This is the line part where the supply is used Line Part Description - This is the line part description Drill to Affected Orders.
  • This drilldown will take the user to the same view as the problem order summary view. However, when we drill to this view, the list of orders that would come up would be the list of impacted orders due to the relevant supply id. For each of these order.shipset, three drilldowns similar to the previous scenario are performed.
  • the Supply Demand the basics of a Supply Chain Execution Application and identify how the SDM Module should be modeled in this regard.
  • Figure 28 illustrates the manner in which a typical company operates.
  • a constrained Supply Plan is developed using a supply Planning Application.
  • fulfillment becomes an issue.
  • supply situations that were assumed might not be valid anymore.
  • SDM helps manage execution in this kind of a disruptive environment.
  • SDM can be thought of as a Supply Chain Execution System that helps companies manage their fulfillment process in the midst of unforeseen supply and demand changes.
  • Exception Monitoring There may be multiple aspects to an intelligent execution system: Exception Monitoring, Resolution to Exception and Tie Back to the Execution System (not part of current SDM scope).
  • Shortage Reporting and Delay reporting based on available state of supply can be thought of as exception monitoring.
  • Resolution to Exceptions include various Order specific recommendations around additional material procurement, expedites of parts of WIP's etc. These actions need to satisfy fulfillment objectives. (Ex. Achieved by the Algorithm). They need to Cause Minimum Disruptions to the Current Planned Execution. (Ex. Use Existing WIP's).
  • Actionable Execution Statements that respect certain rules (Ex. EOQ, Order Modifiers, Aggregation of Recommendations etc.).
  • SDM helps resolve the order fulfillment process through recommending changes to the available supply. This approach is fundamentally very different from planning systems that tend to be more disruptive and do a complete re-planning. SDM Functional Details Viewed in a simplistic fashion, SDM does the following functions. It ranks the Demand, it Allocates Supply to Demand in an order of rank in an n-tiered environment,
  • Ranking Strategy WIP & In-Transit Allocation, N-tier considerations.
  • Ranking Strategy Functionality Functionality Description This feature is part of the allocation feature. Given that executing this part of the allocation process takes time, parts of the computation (range computation) are pre-computed earlier during the ETL run. Ranking Strategies are basically strategies used to prioritize orders in the order of their importance.
  • This order / rank will thus determine the order in which the orders receive supply.
  • the user can define the ranking strategies based on two different strategies: Weighted (Weight) & Ordered-By (Order). Weighted Strategy Referring to Figure 29, a chart is shown of a sample for creating weighted values for Ranking Strategies: Orders are ranked based on a score that is computed for each order. "N" strategies can be defined as a list of strategies. One of them is marked as default to be initially displayed in the allocation module. The various parameters that are used to compute this
  • 35 score will include the following attributes of the order / Forecast. They include: Customer, Schedule Date, B ooked Date, Promise Date, Cancelled Date, Customer Requested Date, Demand Type (Attribute of SO and Forecast), Order Type (Attribute of SO and Forecast), Ship set Revenue, and Ship set Gross Margin. These should be extended to attributes that any other business model will use.
  • the user has the ability to provide different weights to each of these attributes. Each unique selection will constitute a ranking strategy.
  • the score for every order will be computed by computing these weights. Since every attribute is a different dimension, these attributes are normalized with respect to each other. In another embodiment, each attribute is normalized with respect to its own range of maximum and minimum values, in order to compute the score.
  • the normalization method will be described in the Score Computation section of the document.
  • the range for these attributes (used during normalization are set during every ETL run.
  • the various priorities within each attribute can be sourced from a source system when they are non-quantitative attributes. Also, the priorities for non-quantitative attributes are system level and are not specific to any particular strategy.
  • Tie-Break While ranking the orders if the scores are the same, we break the ties first with schedule date. Beyond that, we can rank the orders in a random fashion. Weight / Score Computation Every ship-set will be associated with a particular score and when the user in the allocation module chooses a set of ship sets, it will be ranked / ordered according to the score that has been pre-computed.
  • Ordered-By Ranking Strategy Creating Ranking Strategies • Orders are ranked based on a sorted basis. • "N" strategies can be defined as a list of strategies. One of them is marked as default to be initially displayed in the allocation module. • The various parameters that are used to compute this score will include the following attributes of the order / Forecast. o Customer
  • Order Computation All ship sets are ranked through a prioritization scheme • There are two distinct entities that serve as demand - Forecasts / Sales Orders. • Different attributes of a ship set are given different priorities. • All Ship sets are sorted based on the attribute with the first priority • Now, all ship sets within the same block of the first priority is further sorted among themselves based on the second priority attribute. • This extends till all prioritized attributes that are covered in the strategy are sorted.
  • Sales Order A Schedule Date: Jan, Revenue: lOMillion, Customer Dell Sales Order B- Schedule Date: Feb, Revenue: 15Million, Customer IBM Sales Order C- Schedule Date: Feb, Revenue: 10 Million, Customer Dell Sales Order D- Schedule Date: Feb, Revenue: 10 Million, Customer IBM Working 1)
  • the earliest schedule date is Jan. Hence; the first order to be selected is Sales Order A. Since every other order's scheduled date is the same, the ranking continues. 2)
  • the next attribute is Revenue. Sales Order B gets picked up since Sales Order B has the highest revenue among sales Order B; Sales Order C & Sales Order D. Hence Sales Order B gets selected. Since, the revenues of Sales Order C & Sales Order D are the same, the ranking continues. 3) Customer is a non-quantitative attribute.
  • the various elements have been individually ranked. For example, IBM is ranked ahead of Dell in this example. Hence, Sales Order C is ahead of Sales Order D. 4)
  • the final ranking is Sales Order A, Sales Order B, Sales Order C and
  • the user can define the ranking strategy through the UI. There are two distinct user interactions, defining Ranking Strategies and Managing Strategies.
  • the define-ranking strategy page helps the user define the individual strategies. The two types of strategies can be defined by clicking on the appropriate radio button. All the attributes are listed. The user can enter the weights or the priorities as the case may be. Once defined, this strategy should show immediately (or after next ETL? Run). The screen-shots representing the two strategies are attached below. Referring to Figure 30 and 31 these pages, the user has the ability to update or delete the ranking strategies. Clicking on the strategy name should take the user to the define strategy page for that strategy. Hence, the user should be able to update the strategy. The picture is attached below.
  • WIP Functionality Referring to Figure 32, a WTP page is illustrated.
  • a WIP page is illustrated.
  • a corresponding WIP requirement is issued on the lower level assemblies so that this
  • WLP can be manufactured. There are two ways in which various environments handle this
  • WJJP (or the part of the WJP that is used) will be feasible. In other words, allocate material to their WJP Requirements. It must allocate additional material to a WJP only if used by an actual order or sales forecast. And, it should not use the issued material to any WJP for any other WJJP.
  • WJP's material must first be allocated to satisfy these WIP's first. These WJP's must then be used as a source of supply through Option 1. (This will hence be a pre-processing step similar to how the SDM allocates supply to Orders). However, in these WIP's all the WJP Requirement required would have already been issued through the pre-processing step.
  • Mechanism for WJP's Allocation 1) Allocate in the order of ship set priority 2) Arrange Supply in an order of "Issued Qty against WJP Requirements", ASN's, On-Hand, WJP's and PO's in the earliest available order. (This order should be driven off a system parameter and currently this should be the default order).
  • WTP Flow schedule
  • a Stock-Transport-Order is modeled between two visible sites.
  • an STO can be thought of as a blanket PO that is issued between an OEM and a CM against which a CM executes.
  • An STO is thus an execution statement to a CM to release material in a set time frame.
  • a CM released material against this STO there are two possible states for this material. This could have been received by the OEM and is accounted for in the OEM's inventory pool. In this case, the received quantity in the STO is incremented to account for this inventory.
  • material that has been released by the OEM could be in-transit and not have been received by the OEM. This is modeled as an ASN (Advance Shipping Notice).
  • An STO is a statement of execution to transfer components from one site to another.
  • An STO has a projected completed date and a quantity.
  • the OEM site might have received some parts of the STO and some parts of the STO would be in the state of being shipped/
  • the system needs to accomplish the following things.
  • Multi Sourcing Multi-sourcing environments have a multitude of ways in which they operate. Some of them are described below. 1) Prioritized Sourcing - This is a case in which the OEM usually sources from one supplier and sources from another supplier in the case of unavailability from the preferred supplier. (We don't support this currently) 2) Order Specific Sourcing - If the customer / order has specific sourcing requirements from a supply source due to regional constraints. However, this problem can be modeled as a single sourcing problem and hence is not an issue. 3) Sourcing Percentages - When the OEM has contractual obligations from multiple suppliers; they might employ this mechanism of sourcing a part of their requirements from each supplier. The demand exploder currently uses sourcing percentages logic to solve a multi-sourcing problem.
  • SDM used as a supply-positioning tool Honor Sourcing Percentages at all cost and issue supply recommendations, as this is a long-term supply positioning strategy. We are currently not addressing this capability.
  • a. Split Sourcing In component sourcing environments like at AFC that involves multiple sourcing options, all supply is ultimately dropped at the OEM buffer. The supply here is then consumed. Hence, it would suffice to arrange supply from multiple sources in an as available mode and then source the earliest to satisfy orders. In addition, an overriding factor to this is we don't want to issue new supply whenever it can be avoided. b.
  • Step 1 Propagate demand to both sites
  • Step 2 Source total demand from both sites
  • Step 3 Arrange Supply in two buckets - Real and short and choose top 50 from that.
  • Complete Sourcing The logic here is to source from a single to satisfy a given order in the earliest available mode. However, we will consume real supply before we consume later supply.
  • Short Bundles 4 Choose earliest from the bucket with no shortages (All chosen bundles should be from a single site) 5) If we run out of supply in the first bucket, then choose earliest from second bucket. (All chosen bundles should be from a single site) 6) Throw away unallocated supply. Note: There is no concept of degree of shortness that we present here. A bundle is short if one part is short or if 100 parts are short. This is because it is impossible to distinguish between shortness especially if they occur at different levels.
  • Step 1 Propagate demand to both sites Example.-Demand of 50 is propagated to both sites - Total demand is 50
  • Step 2 Source total demand from both sites
  • Step 3 Arrange Supply in two buckets - Real and short and choose top 50 from that. (Malce sure that all bundles are from the same si Calendar Support in SDM There are three types of calendars that need to be incorporated into SDM. a) Site Calendar b) Site Shipping Calendar
  • Site Calendar The site calendar influences the operations of a company when at that site and will determine the effectiveness of the lead-time. For example, if the lead-time for manufacturing is seven days and the company works only on the weekdays, a manufacturing operation that starts on Monday will only be completed the Tuesday of next week. This will be configurable to affect the lead-times associated with make, buy and transfer. (Manufacturing lead-times, STO lead-times and PO lead-times). As it is site specific, this will apply to the ⁇ eld-At" site where the make, buy or transfer operation is performed.
  • SDM is an order fulfillment tool that helps the scheduling team assess when Orders can be met given the current supply. It also enables the schedulers to assess the supply that is required in addition to the already positioned supply. SDM runs in two modes. One is a daily / bi-daily process that runs based on a pre-specified set of rules
  • Flux is the scheduling tool that triggers SDM runs in specified intervals of time. Flux enables the following: 1) Flux enables the running of SDIVI in pre-specified intervals of time. 2) An XML file can be configured to specify the various properties of this triggered XML run. The various configurations supported are a. Trigger Mechanism - The SDM run can be time-triggered or event triggered. Currently, flux is configured for event trigger. SDM runs after every ETL run (The event here is the end of ETL). b.
  • Pre-set Rule based on a 'Saved SDM run' - A saved SDM is referenced to access the various rules based on which the flux triggered simulation needs to run. SDM follows the rules that this saved simulation has.
  • the various pre-specified rules are:
  • Time Selection can be overridden -
  • the user can specify that the rolling can be overridden by specifying actual dates in the XML document. In this case, the triggered simulation will always pick the same dates.
  • the name for the triggered simulation can be specified in the XML document -
  • the XM document contains the name of the triggered simulation. Every time, a simulation is triggered a time-stamp is attached to this simulation name in order to create a unique simulation. 3) Flux can be scheduled to either run a complete simulation or to extract the demand only based on the rules defined in the XML document and the referenced simulation. a. If the complete simulation is run, then SDM reporting can be used to access the results. b.
  • Order Fulfillment given the current state of supply. If acceptable, the expedite request could be met and the expectations with other customers could be reset. Else, the Order Management person / planner could work with the commodity manager and supplier / CM on the supply side by working on the recommendations provided by the SDM module on the supply side. Thereby the user could better the Order Fulfillment Situation and then on a subsequent run of SDM again assess the impact with the recommendations and then reset expectations with a lesser number of customers.
  • Use Case 3 Regular Recommended Mode In the most normal case, the recommended mode of running is as follows. The company should reflect the rankings of the demand, consistent with overall company objectives. SDM should be run with the following policies. If Shortage - Create New Supply.
  • SDM provides recommendations on both the supply and Demand side. Care should be taken to time the recommended actions in a synchronous fashion. For example, the organization should ensure that customer expectations are not getting reset while supply recommendations are implemented in order that the prior expectations are not reset. For example, SDM could be run in the morning and supply recommendations that come out (Whatever can be accomplished) can be fed into the ERP system. Following this, SDM can be re-run again during the day and this time, the demand side recommendations could be implemented. Hungry Algorithm Introduction The allocation algorithm is an automatic allocation process which assigns end- products, sub-assemblies and components to a sales order by working with bills of material of
  • the algorithm utilizes a Supply and Demand Matching Algorithm for calculating schedules according to available supply and current demand, based on orders.
  • the Allocation algorithm takes into account the complexities associated with sales orders - many line items, ship sets, partial shipments, ship model complete flags - and provides an immense amount of allocation detail when it has finished running. A large number of answers about the allocation can be answered by looking at the result of the algorithm. In addition, a variety of "what-if allocation scenarios can be run by a user of the Hungry Allocation algorithm. Definitions BOM Tree: A Bill of Materials tree for a product describes how the product is constructed, as a set of nodes and arcs.
  • the top node is the end product, intermediate nodes represent sub-assemblies, and leaf nodes represent components.
  • Node A node represents an order, a product, sub-assembly or component. Each node has one parent and one or more children. A top node has no parent, and leaf nodes have no children.
  • Arc Between any parent and child, there is an arc.
  • Bundling Number Every arc is labeled by a bundling number. The bundling number represents the number of units of the child that are required to be assembled into the parent.
  • Bundle The collection of units of a child that can be moved up an arc to a parent.
  • Bundling Condition This is the condition under which a node can assemble the bundles received from its children and create a bundle of its own.
  • the default bundling condition is: a bundle must contain one bundle from each of the children nodes.
  • Supply Available supply at any node. This represents inventory, WTP and PO's, or as selected by the user. Supply is stored in a single table in memory. Therefore, repeated nodes in a part look at the same table when they need supply. If supply is allocated to a node, it is correspondingly reduced from the supply table, thus making it unavailable to a second occurrence of the same node, which will look at the same (single) supply table.
  • Hungry Allocation stores allocation as a nested list of assemblies, sub- assemblies and components.
  • An allocation list provides (in addition to the quantity allocated) the exact manner in which that allocation has been theoretically assembled.
  • an allocation at the top node for product P might look like this: 5 + 2(1,2) + 3((2,4), 2(4,7)) ...
  • the allocation consists of 5 units of P, 2 units of P assembled from its sub- assemblies (which provide 1 and 2 units respectively), and 3 units of P assembled from sub- assemblies which in turn have been assembled from their own components.
  • Algorithm The algorithm works on a top down strategy, starting at the topmost node (product or order) and moving down the BOM tree if and when needed. Node Operations Two recursive operations describe the algorithm: 1. Calculate the move-up number, m_i, for each sibling node: divide (and truncate to integer) the QOH at the node by the bundling number above it. 2.
  • Hungry Allocation can work in two modes: Storage and Hungry:
  • the allocation can now be read from the allocation list at the topmost node.
  • This allocation is maintained as a nested list of sub-assemblies and components. It shows the exact manner in which units of the product can be assembled.
  • the first mode of operation will stop as soon as a short component is identified, or when allocation is complete.
  • the second mode of operation is more powerful. It will always allocate fully, because all shortages will be made up by fictitious units. In the process, it will be able to identify all short components, their shortage quantities, and provide a great deal of insight into the allocation scenario.
  • we assume that the algorithm is run in the Hungry mode. Features of the Hungry Allocation Algorithm are numerous.
  • the algorithm attempts to carry out a complete allocation, and stumbles upon shortages as they occur. This allows the algorithm to gain a far greater insight into the nature of the shortage (which components experience a shortage first? How many units could we have assembled (and shipped) before the shortage made itself felt?) . It moves in chunks toward the final goal of complete allocation. In the worst case, it reduces to "allocate one at a time”. This worst case, however, will rarely occur unless the BOM is unrealisticly complex, and supply is distributed in an unreasonablely complex way at all levels of the BOM. In all cases (even for complex BOM's), the algorithm will speed up after the supply at intermediate levels has been exhausted.
  • the algorithm can be very efficient, and its worst case efficiency can be calculated.
  • the general policy of the algorithm is to go down the BOM tree only when absolutely necessary, and to never go down more than required. So, the supply at any level will typically not consist of too many nested lists (except at the top level).
  • an order node is not needed. There can be one tree for every product, and each tree is independent, except in reading from the same supply table. It will not allocate unnecessary components to an order: for instance, some orders require products, components and sub-assemblies in bundles, (e.g. some sub-assemblies are
  • the allocation list at the product node describes the complete allocation when the algorithm stops. Before moving on to the next product, the supply tables in memory will have to be adjusted to subtract the allocation already done in the current product. This can be done by looking at the nested allocation list at the product node. This also means that intermediate bundles which have been pushed up in the current BOM will be destroyed, because they exist only as theoretical assemblies. If a component goes into one and only one sub-assembly, then the "aggregated BOM" which is generated by the Hungry Allocator can provide information to speed up future allocations, because it has already assembled (theoretically) those components and made them available as sub-assemblies.
  • SB1 and SB2 are existing STO's placed by sitel on site2 2.
  • SB3 and SB4 are existing STO's placed by sitel on site3 3.
  • the supply tied to an ASN is received, the received qty of the corresponding STO is increased accordingly, and the ASN vanishes from the database. So it is safe to assume that an ASN will deliver all its released_qty on its scheduled receipt date. (An ASN that is received will probably go into the receipts_ft, but that is not of interest). 5.
  • the qty to be delivered by a WTP is (start - complete), where complete_qty has been adjusted with on-hand.
  • the qty to be delivered by an STO is (original - received) where received has been adjusted with with On-Hand (Lou seems to use Open Quantity for original - received) 6.
  • On-Hand at that supplying site is fully available for use to meet other existing STO's or to make new STO's 7.
  • Issued Qty we always means "unused issued” in wip requirements. We must use the complete qty of the WTP to calculate the unused issued qty for its corresponding wip requirement.
  • pulling operation terminates when the pulling (parent) node has pulled as many bundles as the minimum move_up number of its children.
  • a pulling operation terminates in either of two situations: A. The pulling (parent) node has pulled as many bundles as the minimum move_up number of its children. B. The WTP (or STO) being constructed is complete, (as in Step 11). In other words, "one pull" breaks up into as many pulls as there are pre-defined WIP's or STO's. After the end of each pull, the parent node attempts to move up the tree.
  • QOH(A) 2.
  • PO(A) 2. Committed to WP2.
  • M(A) 5 30.
  • Sourced(B) 3 SBl + 1 SBl + 3 SB2 + 9 NEW_STOl + 4 SB3 + 3 SB4 + 57 NEW_STO6.
  • M(B) 40 31. Push up 4 bundles of A and B, one at a time.
  • Allocated(WP2) 7. Complete? YES 32.
  • D(P) 50 33.
  • Allocated(P) (5 + 2 WP1 + 3 WP2
  • Sourced(B) 8 NEW_STOl + 4 SB3 + 3 SB4 + 57 NEW_STO6.
  • M(B) 36 37.
  • Allocated(WP3) 1. Complete? NO 38.
  • D(P) 50 39.
  • Allocated(P) (5 + 2 WP1 + 3 WP2
  • M(A) 31 49.
  • Sourced(B) 2 SB3 + 3 SB4 + 57 NEW_STO6.
  • M(B) 31 50.
  • D(P) 50 52.
  • Allocated(P) (5 + 2 WP1 + 3 WP2 + 4 WP2 + 1 WP3 + 4 WP3 + 31 NEW_WTP2) 53.
  • Allocated(B) 3 SBl + 1 SBl + 3 SB2.
  • D(B, site2) 73 23.
  • Allocated(WBl) 11 - 2.
  • M(B) 9 24. Push up 9 bundles of B , one at a time.
  • D(B, sitel) 80.
  • This PO may be for a larger amount than we need, because some Y may be sitting around in issued_qty, but we have no way of knowing that. 33.
  • Push up 1 bundle of X and Y(X). Allocated(WB 1) 12. Complete? YES 34.
  • CREATE NEW_STO2 35.
  • D(B, sitel) 80.
  • Allocated(B) 3 SBl + 1 SBl + 3 SB2 + 9 NEW_STOl + 1 NEW_STO2.
  • D(B, site2) 63 38.
  • Allocated(B) 3 SB1 + 1 SBl + 3 SB2 + 9 NEW_STOl + 1 NEW_STO2 + 2 NEW_STO3 + 2 NEW_STO4.
  • D(B, site2) 59 57.
  • Allocated(X) 59 NEW_PO2. Committed to no WTP.
  • M(X) 59 59.
  • Allocated(Y) 62
  • Source B 18.
  • D(B, site3) 2 19.
  • M(B)
  • the invention utilizes a Supply Demand Match Algorithm, where the discussion below describes one such embodiment of an algorithm.
  • This algorithm allocates supply to demand using a propreitary algorithm.
  • P be a node in the BOM/BOD tree
  • N be the set of sibling nodes which are children of P, n ⁇ , ⁇ % ⁇ , ..., n #
  • Demands Let d ⁇ (ni), d 2 (n,), ... , do(nj) be prioritized demands at node n,-.
  • a prioritization scheme for demand is [demand type, required date].
  • Demand types can further by prioritized as: Demand associated with WTP's(STO's), unassigned demand.
  • a node can have a BOM parent or a BOD parent, but never both. Therefore the demand at a node can be associated with WIP's or STO's allocated to its parent, but never both.
  • D [number of WTP's(STO's) allocated to node P, number of WTP's(STO's) allocated to node P + 1] 1.3 Supply Records A supply record is a collection of identical (or indistinguishable) units. The types of supply records supported by SDM are On-hand, Issued Qty, AS ⁇ , PO,
  • Supply types can further be prioritized as: Issued Qty(ASN), On-hand, PO, Allocated WTP(STO), New WTP(STO) Because a node can have either a BOM or BOD parent, Issued Qty and ASN's cannot occur together at the node. Similarly, because a node can either be BOM or BOD, WIP's and
  • Q(P, Ji t ) be the bundling number of node ⁇ ,-, defined as the number of units of child ti t that are required to make one unit of parent P.
  • a supply bundle is a supply measure (consisting of fractional, single or multiple supply records) which contains exactly one bundling number of units.
  • b ⁇ [dy(ni)], b 2 [dy(ni)], ..., b ⁇ , [d y (n ⁇ )] be supply bundles in the supply manager that are eligible to meet demand d y at node n ⁇ .
  • a move up number is a collection of one or more supply bundles at node iii that are eligible to meet demand d y . When a move up number is greater than 1, it refers to identical supply bundles.
  • supply bundles may be eligible to meet more than one demand at n ⁇ , M y ⁇ must be determined for one (prioritized) demand at a time, not for all demands together.
  • Supply Demand Match The algorithm will be described as a set of operations at the children of nodes.
  • a node is a junction in the BOM tree of an assembly. Allocation of Supply Records, demand d y at node « / At node n ⁇ , the supply manager determines eligible supply records, S j [d y (ni)], for demand d y , by matching (part, sites) of the demand with those of the supply.
  • Allocated supply records for demand d y at node ii are: Sj[dy(ni)] 6 (s ⁇ [d y (n , ..., s S y ⁇ - ⁇ [d y (ni)]), and f ⁇ - ⁇ i *-*( « «)]) units of s S y ⁇ [d y (n ]
  • Each demand dy at node n t has its own list of eligible supply ⁇ [ ⁇ (/i,)], which is to be used when calculating move up numbers. These lists may have significant overlap across demands, and will be used up by each demand in order of demand priority.

Abstract

A system is provided configured to manage supply chain information according to detailed supply criteria over a broad time line. The system includes a prioritization module configured to prioritize customer product orders according to an supply and demand matching algorithm for calculating predetermined customer criteria and business policy, wherein the algorithm accounts for predetermined relative priorities based on historical customer information including past, current and projected customer product demand. The system further includes an assembly planning module configured to establish a unit assembly schedule according to scheduled availability of sub-units.

Description

U.S. Non-Provisional Patent Application
Title: System and Method for Supply Chain Management to Allow Intelligent Shipment Scheduling that Accounts for Shortages and Delays Prior Applications This application claims priority from United States Provisional Patent Application No. 60/531,401, filed December 19, 2003.
Background Most business entities have a perpetual need to inventory and exchange data among other business entities, both internally and with customers. Manufacturers, for example, have a constant need to inventory their product data in order to keep production flowing efficiently. As business arrangements become more complex, it becomes important to carefully organize and retrieve data that is shared among business partners. In some product markets, inventory orders can impact a business in ways that are difficult to predict.
Businesses may depend on projections of such impacts to make informed decisions in a short amount of time. They may also be critical to a business 's competitive edge. This becomes important as manufacturers are now outsourcing more and more products, further depending on outside business partners. When certain supplies or demands of products or individual components change, it affects inventory, product releases and other business-critical operations. To complicate matters further, these business partners often exchange information electronically on different and incompatible formats. As a result, many businesses resolve this problem by actually exchanging paper documents among themselves. This of course seems absurd in light of modern day advancements in computer technology. However, most businesses that focus on producing products will not easily change their business practices at the administration level in fear of inhibiting their product flow. In order to gain acceptance by businessmen, any new method of exchanging data needs to be easily adaptable. One approach is to custom design a system suited for a particular business organization. Many inventory systems exist that are particularly tailored to a user's needs. They are developed from basic software code routines that are used as building blocks. In reality though, these systems require that software code be written from scratch in almost every new application. The software architecture of such systems must be created and developed on an individual application basis. The result is a very high up front cost for each application. In conventional applications, separate modules are created to perform certain tasks related to supply chain control. In order to monitor a supply chain in a meaningful manner, operation modules must integrate to some extent. Typically, modules such as reporting tools are custom made to a user's preferences, while other modules critical to the function of the reporting tool, such as data loading and data mining tools, are developed separately. The data loading and mining tools typically operate in a relational database, which requires some type of dynamic catalog to operate. In order to combine a reporting module with these operations, it must be integrated to use such a catalog. Unfortunately, integration of these entities is usually an afterthought. As a result, integration is very complicated, requiring special software code to build relationships among the modules. The end result is usually an inflexible custom application that is developed for a particular use, requiring ongoing development and maintenance at the database level. As a result, end users must rely on highly trained individuals to maintain such systems on site. Therefore, there exists a need for a solution that can centralize information and allow access to certain supply chain information in an organized and useful manner. Such a solution would obviate the need for first line support at the user's site. As discussed below, the invention accomplishes this in a unique and elegant manner.
Brief Description of the Drawings Figure 1 illustrates system process configured according to the invention is illustrated in a diagrammatic manner, where the method 100 is configured to establish orders in a supply chain managed according to the invention. Figure 2, a flow chart 200 illustrates the operation of a system according to the invention from a user's point of view. Figure 3, a system flow diagram 300 is illustrated. Figure 4 illustrates a user input page. Figures 5 and 6, input parameters and their related criteria are illustrated in table form. Figure 7 is a user interface for a user to review demand dates. Figure 8, this webpage view shows all the ship sets and the details associated with them. In Figure 9, demand quantity is illustrated. Figure 10, a user interface is illustrated. In Figure 11, a user interface is shown for choosing supply. In Figure 12, a user interface is shown for observing work in progress. In Figure 13, a chart illustrating parameters for choosing by the user is illustrated. Figure 14 illustrates how parameters in Figure 13 can be modified. In Figure 15, a user interface is illustrated for selecting parameters. In Figure 16, user interface for confirming selecting parameters is illustrated. In Figure 17, a sample scenario is illustrated. In Figures 18 and 19, an Order Summary Drilldown Overview is illustrated. In Figure 20, a drilldown view is illustrated. In Figure 21, this view basically details all those supply that have an action "None" associated with them. In Figure 22, a drill down view is illustrated. In Figure 23, a parts summary view is illustrated. In Figure 24, Parts Summary Drilldown Overview is illustrated. In Figure 25, drill down details are illustrated. In Figure 26, this view is similar to the previous view of Figure 25. In Figure 27, the various columns in this view are explained. Figure 28 illustrates the manner in which a typical company operates. In Figure 29, a chart is shown of a sample for creating weighted values for Ranking Strategies. In Figure 30 and 31 illustrates the user has the ability to update or delete the ranking strategies. In Figure 32, a WIP page is illustrated. Figure 33, illustrates Buildable Supply Problem Supply and STO Functionality. Figures 34-36 illustrate process steps. Figures 37-39 illustrate process steps. Figure 40 illustrates a flow diagram of some scenarios.
Detailed Description A system and method configured to manage supply chain information according to detailed demand and supply criteria over a broad time line is provided. The invention resolves an ongoing problem that supply chain management systems face, where inventory visibility is laclcing, and addresses specific problems of shortages and delays. This is primarily a result of the difficultly of managing ever changing inventories of incoming supplies and lead times of product units and sub-units, such as component parts. The invention provides a prioritization module configured to prioritize customer product orders according to customer criteria, and business policy. The prioritization is set according to a Supply and Demand Matching (SDM) algorithm that, when executed, calculates predetermined customer criteria and accounts for predetermined relative priorities based on historical customer information, such as past, current and projected customer product demand. An assembly planning module establishes a unit (such as a finished product) assembly schedule according to scheduled availability of sub-units (such as component parts). A scenario module is configured to generate a unit delivery scenario according to customer priority as determined by the prioritization module. An assembly schedule is then generated as determined by the assembly planning module, where the scenario module defines a unit delivery scenario that provides a delivery schedule. This delivery schedule may enable production of partial shipments of available units at scheduled times based on scheduled availability of sub-units, when complete shipments are not available at particular times. The delivery schedule accounts for various constraints including manufacturing lead times and other criteria. Other criteria may include capacity constraints, whether they are constrained by the capacity of the manufacturer or other source or supplier. The criteria may also include transport time constraints, such as between different suppliers or to customers. Criteria may further include constraints imposed by
Engineering Change Orders (ECO's), which effectively change the manner in which a part is manufactured, starting on some date. Criteria can be established, and business rules can be set to prioritize orders. For example, if you have a large order for a large customer, you might want to put them out front in the delivery schedule. The system can also rank strategies according to criteria. According to the invention, a producer can allow prioritization based on a host of criteria. Conventional systems allow prioritization based on some well-known order attributes, such as scheduled ship date, or order revenue. A system configured according to the invention can allow, for example, prioritization of customers themselves, prioritization by margin, by channel, by type of demand, or other criteria and combinations of criteria. As another example, if a particular company needed to give preference to orders placed by the government, and against orders placed by private parties, the invention enables a user to use that criterion for prioritization. According to the invention, a user can operate a tool to run a scenario. A user can then get exceptions and recommendations in a scenario. The scenario operation is fulfillment based, allowing a user to respond to changes to supply and demand on the fly. The invention would further enable a system to recommend new purchase orders, new work orders, and new stock transfer orders. Unlike conventional systems, a system configured according to the invention is based on "fulfillment" of orders, rather than simply "planning" of orders. The invention further provides the ability to establish a weighted score, an overall numerical score for each demand (whether a sales order or forecast), that allows the system to prioritize that demand. It may be computed on the basis of many criteria specified by the customer. The SDM matching algorithm considers the weighted score, in that it allocates supply to demand in order - demands with higher weighted scores are met first. Depending on properties of demand and supply, the SDM algorithm handles shortages and delays differently. For example, if new supply may be issued for a part, SDM issues new supply. If new supply may not be issued for a part (because the part is a life-time buy under industry terms), then SDM will not issue new supply for the part, and the system will ship the corresponding sales order partially, assuming only a part can be constructed without issuing new supply for that part. If a sales order is marked "Ship On Time", then SDM will ship it only if it is on time, or it will not ship it. IF a sales order is not marked 'Ship on Time", then SDM will ship it even with a delay, but will clearly indicate the new ship date Referring to Figure 1 , a system process configured according to the invention is illustrated in a diagrammatic manner, where the method 100 is configured to establish orders in a supply chain managed according to the invention. In step 102, an order is received, and it has a weighted score established in step 104. The priority module 106 establishes priority criteria according to customer priorities, which are established by the user or other entity, and other criteria, including capacity, timing, ECOs and other criteria. Next, the supply and demand are assessed according to the order and related information in step 108. It is determined whether a new supply is authorized in step 110. If it is, a new supply is issued in step 112. If not, then the order is filled by existing supplies or by other means. If the order is not allowed to issue new supply and it requires new supply, then it can be shipped partially, or not at all, but cannot be shipped fully. Next, it is determined whether partial shipments are authorized in step 114. If they are, then the supply and demand are assessed in step 116 in light of partial shipments, a partial shipment ichedule is generated in step 118, and the partial shipping is effected in step 120. If partial shipments are not authorized, then the system establishes that the entire order is to be shipped in step 122. Next, it is determined whether the shipment is to be done on time only in step 124. If yes, then it is determined whether the shipment is scheduled on time in step 126. If it is not on time, then the order is cancelled in step 128. If it is on tome, then the shipping order is completed in step 130. The invention is directed to primarily two problems, shortages and delays. The definitions of those are provided below. A shortage is where the allocation of demand results in a shortage problem if there is a lack of components. (Only buy parts). It is important to note in this definition is that this shortage could occur within lead-time or outside the lead- time of the product. Thus, an order would be considered short simply if there are not enough sub-components available (on/hand) or on order (WTPs, POs, Intransit) to build the end-item associated with the order. It is quite possible that the sub-component could be procured to meet the order on its schedule date. However, irrespective of this, the order may still be defined as a short order. Shortage Policies A system configured according to the invention would have policies established that determine the behavior of the SDM algorithm when they encounter a shortage problem. During allocation, for example, if there is not enough supply at the leaf node (Shortage), then the algorithm creates a new Supply to fulfill the order and recommends the same. When the SDM mechanism encounters a Shortage problem while allocating supply, the algorithm does not issue new supply and thereby fulfills the order partially to the extent of the available supply. Partial shipping may applicable only when there is a single line ship set. When, there are multiple lines that are defined as part of the ship set, partial will result in no allocation for the ship set. When there is a shortage problem, SDM will allocate supply to only those orders that can be completely fulfilled given the available supply. The decisions are based on the available supply and not based on potential new supply. Delay Policies A delay may be defined as an order that cannot be delivered before the schedule date of the order, given the available supply (current scheduled delivery date) and the new recommended supply (only leaf node new PO's). However, embodiments may invoke two restrictions. First, the allocation mechanism may not issue any new recommended supply if existing supply can meet the order. In certain cases, it is quite possible that new supply could satisfy the order on time as opposed to existing supply. However, one of the key elements of SDM is that excess supply should not be recommended. Instead expedite messages on pre- planned supply should be recommended. Second, a new supply recommendation is based on the policies that are chosen in the case of shortage policies (Shortage). Thus, only when the user chooses "Create New Supply" will supply be recommended. According to the invention, a system is provided that has policies that determine the behavior of the SDM algorithm when they encounter a delay problem. During allocation, if the supply considered (New & Existing) result in a delay problem, then the algorithm still allocates supply and provides re-conciliation messages on solving the delay problem. (Through Best Dates). When the SDM mechanism encounters a delay problem while allocating supply; the algorithm allocates supply and fulfills the order partially. Thus, the algorithm does not delay the partially allocated order. Ship only on-time Orders - In the case of requests to ship only on-time orders, when there is a delay problem, SDM will allocate supply to only those orders that can be completely fulfilled on time given the available supply state. The decisions are based on the available state of the supply and not based on better possible states, known as Best Dates). Shortage and Delay Policies in Conjunction One of the key points that needs to be understood in this regard is that Shortage and Delay are two independent problems. Hence, these two have different policies to solve each problem. We should however understand how different policies work in conjunction with each other. For example, if new supply has been created based on shortage policy (Create New Supply), this supply might not be recommended if it causes a delay and the delay policy chosen is (Ship Partial). Similarly if a user chooses Reconcile Delayed Orders and Chooses Ship Partial as their policy on Shortage, then the system will not issue new supply. In principle, the basic logic of how these play with each other can be understood by applying the shortage policy first and then the delay policy. Referring to the figures, one embodiment of the invention is illustrated in an example of a supply chain management application that is configured to perform supply and demand matching and to uniquely schedule deliveries according to available supply and current demand, where the demand may be represented by purchase orders, bills of material (BOMs), or other well known orders for desired items or services. UI Flow The embodiment described herein is illustrated from a user's point of view, described and illustrated in terms of UI Flow for the application. The embodiment description begins with a high-level flow model of the SDM Module. Following that, each box (Corresponding page in the SDM Module) is detailed out. This document is split into the following sections - User Input, Output and Saved-User- Inputs Section. The User Input defines the various data inputs needed for the allocation feature. The output section lists the outputs that the user derives out of this feature. The Saved-User-Inputs Section allows the user to retrieve the various inputs that the user chose in a particular SDM Run. Functional Flow Diagram Referring to Figure 2, a flow chart 200 illustrates the operation of a system according to the invention from a user's point of view. In step 202, the system receives the user's input. Then, the demand criteria are established in step 204. Within this step, demand is chosen in step 206, a user may edit the demand dates in step 208, then rank demand terms in step 210, edit the demand quantity in step 212, then create orders in step 214. Next, in step 216, the supply is established; where the supply criteria are established in step 218 and partial shipments, if authorized, are established in step 220. Once all of this data is received, then the supply and demand parameters are established in step 218. The user can confirm the criteria in step 220, and store the results in step 222. Referring to Figure 3, a system flow diagram 300 is illustrated. The user input is received in location 302 at stage 1. In stage 2, the demand system 304 allows a user to choose demand the demand. For the remaining stages, the operations module 306 allows a user to establish an order and its priority. In stage 3, the system allows a user to view and edit demand dates. In stage 4, a user can view and edit the supply. In stage 5, a user can select parameters for the order. In stage 6, a user can confirm the order. The allocate criteria, results and the supply and demand details are then stored in the user input storage 308. According to the invention, a user is enabled to constrain the demand for consideration in the allocation mechanism. Thus, by specifying parameters that are tied to the ship sets/order, the user can pick only those ship sets/orders of interest. This will enable the user to contain the scope/analysis of the allocation mechanism to only those demand signals that he/she is interested in. The following parameters are used in this process: SO Slotting Criteria: This parameter works in conjunction with the parameter SO Date Range. There are three possible date ranges for selecting SO's: CRD, Promise Dates and Schedule Dates. Hence, when a user chooses the selection " CRD" for the "SO slotting criteria" and chooses an SO Date Range, the application will return all SO's whose CRD lies in the date range specified. Number of Top Orders: This parameter limits the number of orders that are considered. This parameter works in conjunction with the parameter "Ranking Strategy". The Ranking strategy ranks the selected orders/ship sets in a particular priority sequence. The number of Top Orders picks up the "n" number of ship sets/orders starting from the top ranked and returns them for consideration for the allocation mechanism. Ranking Strategy: Through a pre-defined set of rules, (Described in the Ranking Strategy section), the user will be able to prioritize the demand based on some attributes of the demand. For example, the user can prioritize demand in the order of their margins. This will become important because supply will be allocated to demand only in that fashion. This ensures that in the case of a shortage, the prioritized orders are not starved of supply. This forms the basis of the SDM Feature. Parameters Choosing Demand Figure 4 illustrates a user input page. Referring to Figures 5 and 6, input parameters and their related criteria are illustrated in table form. Figure 7 is a user interface for a user to review demand dates. Referring to criteria marked with a "*", these parameters are dependent parameters on the parameter "demand type". Thus, these parameters get displayed when the user chooses either forecast. Referring to items marked with "**", these parameters are dependent parameters on the parameter "demand type". Thus, these parameters get displayed when the user chooses either "Sales orders". According to the invention, the ranking function, Referring to Figure 8, this webpage view shows all the ship sets and the details associated with them. These details include: • Original Rank - This is the rank that has been computed for the demand element. The user though has the flexibility to change individual ranks and re-prioritize on an exception basis with the help of the what-if capability • New Rank - This is a what-if rank that the user can use to over-ride the current rank • Demand Type - This is the demand type for the demand element • Demand quantity, Figure 9. • Order-Ship set / Forecast - This is the identifier for the demand element. This basically provides the identifier for the forecast and the ship set. For the ship set, the identifier is the "Order.Shipset-No". A link is provided from each of these identifiers to be able to view and edit the line details (Qty of the lines). • Order Type - This is the Order type for the ship set • Customer - Customer for the ship set / forecast • Order Status - Status for the Order. In the case of forecasts, this will be blank. This will be picked up from the ship set-status in dt_sales_order_shipset. • Original Revenue - This is the original revenue of the Ship set / Sales Order. In the case of sales_order, this should be picked up from Total_selling_price from sales_ft. In the case of a forecast, this should be computed as "ASP (PCB)*Current Qty (Forecast_ft)". • Customer Request Date - This is the CRD for the demand element. This should be picked up from the CRD in ft_sales_shipset (our own computed table). In the case of a forecast, the forecast-date (start or end-date of the period based on what is populated in forecast_ft will be used) • Original Scheduled Ship Date — This is the scheduled ship-date for an order.
This should be picked up from the schedule_ship_date in ft_sales_shipset (our own computed table). In the case of a forecast, the forecast-date (start or end-date of the period based on what is populated in forecast_ft will be used) • New Schedule Ship Date - The user has the ability to change the schedule date of the order by plugging in a what-if date. This new-date will be the driver for the allocation mechanism. The what-if Date initially displays the original schedule date of the ship set by default. • Cancel-by Date - This is the Cancel by Date for the demand element. This should be picked up from the Cancel-by-Date in ft_sales_shipset (our own computed table). In the case of a forecast, this should be blank. This pop-up can be accessed from the icon "i" next to the rank of each ship set / forecast. This provides the details behind the computation of the score that is used to rank the demand elements. The higher score demand is ranked higher than the lower score demand. The logic for the computation of the score is provided in a subsequent section on ranking strategy. This picture is for the weighted strategy. (The order-by strategy will have fewer columns.2B - View and Edit Demand Qty The view can be accessed from the "view and edit demand dates" view by clicking on the Order: ship set / Forecast field. This view displays the lines and the details of the lines belonging to the selected ship set. The various details selected in Figure 9 are: • Line - The Line number is displayed here. • Part - This displays the name of the part. • Description - This details the description associated with the part name • Order / Forecast Qty - This lists the original Ordered / Forecasted Qty. In the case of forecasts, this should be the "current qty". • Shipped Qty - This lists the qty shipped already against this sales-line. This will be blank in the case of forecasts • Canceled Qty - This lists the qty that has been canceled. This will be blank in the case of forecasts • Allocation Qty - This is the qty that would be allocated. This is calculated as (Ordered Qty - Shipped Qty - Cancelled Qty). This is the qty that will be used in the allocation feature. Supply will hence be allocated to fulfill this demand qty. • What-if-Qty - The user can over-ride the allocation qty by putting in his/her own qty. By default, this field would be left blank. Referring to Figure 10, a user interface is illustrated. The view enables the user to create a what-if Order that can be included in the pool of demand that the user has already chosen. Hence, this new what-if order will have supply allocated in its relative priority with respect to all other orders. This functionality can be used when a user wants to understand the impact of a sudden huge order that needs to be met short-term. Based on the impact of this new order, the user could go back and promise appropriately and hence enter into the system. The various fields are as follows: • Rank - This is the rank that can be assigned to the new order. • Demand Type - This is the demand type for the what-if order. It cannot be changed and is always set to What-if. • Order: Ship set / Forecast - This basically provides the identifier for the forecast and the ship set. • Order Type - This is the Order type for the ship set • Customer - Customer for the ship set / forecast • Order Status - Status for the Order. • Revenue - This is the original revenue of the Ship set / Sales Order • Margin - This is the margin for the ship set. • Scheduled Ship Date - This is the scheduled ship-date for the new order. • Promised Date - This is the promise date of the new what-if order. • Booked Date - This is the booked date of the new order. • Customer Request Date - This is the Customer Request Date for the new order. Available Qty - This is the Supply Qty that is available for Allocation. This is defined as (Ordered - Cancelled - Scrap - Completed), wherever the fields are applicable. What-if Qty - The user can override the system. Schedule Receipt Date - This is the schedule date of the Supply PO - PO Schedule Date WIP - WIP Completion Date ASN - ASN Receipt Date On-Hand - Sys.Date What-if Date - The user can override the system. Site - This is the site where the supply will be received. Supply Site / Stockroom ASN - Supply Site PO - Supply Site WΓP - N / A On-hand - Stockroom Select Parameters Referring to Figure 15, a user interface is illustrated for selecting parameters. Referring to Figure 16, user interface for confirming selecting parameters is illustrated. Referring to Figure 17, a sample scenario is illustrated. The input parameters are the following: 1) Demand Type - This is the demand type associated with the demand element 2) Order Type - This is the order type associated with the demand element 3) Order Status - This is the status of the demand type 4) Analysis name - This refers to the simulation name that was run. We should ensure that we don't show other types of Simulations here. 5) Customer - This is the customer name for the Order 6) Problem Type - This is the problem type associated with the demand element. This is computed by SDM 7) Product families - This refers to the product families of the end-assembly of the demand 8) Commodity codes - This refers to the commodity codes of the end-assembly of the demand 9) Parts - This refers to the parts of the end-assembly demand
13 10) Schedule Date - This refers to the schedule date of the demand element 11) Cancel by Date - This refers to the cancel-by-date of the demand element 12) Promise Date - This refers to the promise-date of the demand element 13) Customer Request Date - This refers to the CRD of the demand element. Although the user has already chosen their input criteria in the allocation, this parameter constraint allows the user to look at only the outputs that he/she is interested in for one particular analysis. It is quite possible that different users (ex. Order Fulfillment Personnel), looking at their own portfolio of orders would like to see only those orders that they would be interested in. This Figure 17 illustrates the related details on the order. This gives the user a sense of how the order has been allocated, its financial impact and the associated problems. This view is at the ship set / forecast level. The details of the various columns are as follows: • Order Ship set Number - This will be the identifier for the ship set / forecast for which supply has been allocated. In the case of a sales-order, this will be "Order- Number. Shipset-Number". In the case of a forecast, this will be the Forecast name. • Order Status - This is the status associated with the ship set. (Where do we get this from?) • Demand Type - This is the demand type associated with the order. This is an attribute on sales_ft • Order Type - This is the Order type, again an attribute on sales_ft. • Held For - This will be the Site for which the Sales Order is Originally Held for. • Order Site - This will be the demanding site • Supply Site - This will be the supplying site • Rank - This will be the Rank of the ship set / Forecast that was used during the
Allocation, based on the inputs that the user provided. • Problem Type (Discussion) - This would indicate the various problems that an Order.Shipset / Forecast would have at the end of the Allocation. The various problem types would be a delay, where an Order is delayed if its available date is later than its required date. Essentially, this implies that given the available state of the supply, the order cannot be satisfied on the required date. Note that this condition would happen only if the user had chosen, Reconcile Delayed Orders. Order is supposed to be short if components need to be procured (buy / transferred) or manufactured (Make) in order to build the final end-assembly.
14 However this definition is configurable based on three system level-parameters - Short for Make Part, Short for Buy Part and Short for Transfer Part. Hence, for example, it is possible to define shortage only when you have a new PO / STO recommendation (buy / transferred). However, an order that contains a new WIP need not be identified as short if the system parameter associated with "short for a make part" is turned off. Hence, in our current model, we will have three system level parameters each for make / buy / transfer that can be turned off or on to define shortage in a configurable manner. Note, that this definition of short is different from the shortage definition (only buy), used in the inputs to make the Allocation Shortage Policy Decisions. This condition would happen when the user selects any shortage option. However, buy component shortage would happen only if the user selected "Create New Supply" in the user parameters. Partial - An Order.Shipset is considered partially allocated if the end-assembly built is lesser than the required quantity. It should be noted that a partial condition does not have anything to do with the scheduled date. Partial simply implies that the allocation is partial. It could be before the scheduled date or later. A partial is caused only when the user chooses either "ship partial" on the delay policy or "ship partial" on the shortage policy. No Allocation - An Order.Shipset is reported with "No Allocation" if no material has been allocated to the order. A "No Allocation" is caused only when the user chooses either "ship only complete" on the delay policy or "ship only complete" on the shortage policy. Short and Delay - An Order could be both short and delayed if in addition to being short, the end item is also delayed beyond its scheduled date. It should be noted that it is not necessary that the short components cause a delay. A delay could be caused either because of the new components or due to an existing supply source. This problem would be reported only if the user had chosen "Create New Supply" for the Shortage Policy and "Reconcile Delayed Policy" for the Delay Policy Delay and Partial - An Order.Shipset is considered partially allocated if the end- assembly built is lesser than the required quantity. In addition, this partially allocated Order.Shipset is also delayed beyond its schedule date. This problem would be reported only if the user had chosen "Partial" for the Shortage Policy and "Reconcile Delayed Policy" for
15 the Delay Policy. This implies that the partial decision was taken because the user had chosen to allocate partially if the allocation mechanism encountered a shortage problem. Short and Partial - An Order.Shipset is considered partially allocated if the end- assembly built is lesser than the required quantity. In addition, this partially allocated Order.Shipset is short. • This problem would be reported only if the user had chosen "Create New Supply" for the Shortage Policy and "Partial" for the Delay Policy. This implies that the partial decision was taken because the user had chosen to allocate partially if the allocation mechanism encountered a delay problem. • None - This indicates that the order was allocated without any problem. This indicates that supply was available at the right place at the right time to build the order on time. • Customer Name - This is the name of the customer associated with the ship set / forecast • Booked Date - This is the date the order was booked • Customer Request Date - This is the date that the customer has requested the delivery • Promise Date - This is the date on which it was promised to the customer • Scheduled Ship Date - This is the scheduled ship-date for an order. This should be picked up from the schedule_ship_date in ft_sales or dt_sales_order_shipset? In the case of a forecast, the forecast-date (start or end-date of the period based on what is populated in forecast_ft will be used) • Available Date -There are two possible streams of actions that the Allocation mechanism suggests in the case of a delay. One set of recommendations is on the supply side (Best Date based) and the other recommendation set is on the demand side (Available Date based). Thus the available date is the date on which the ship set / forecast will be available given the current state of supply. In a subsequent drilldown, we provide the available dates at all the component levels. Theoretically, the available date of all components could be built up to provide the available date at this level. • There is just one caveat to the calculation of available dates. In the case of on- hand, In-Transit and PO as supply, the available dates are simply defined as system dates, in- transit dates and PO dates respectively. However, in the case of a WIP and an STO, the available date at this level is constructed with the feasible available dates.
16 • Also, it should be noted that the available date would be different from the required date only if the user chose "Reconcile Delay" as the delay policy. Else, partial allocation or no allocation would result in the available date and the required date being the same. Shortage Policies have no bearing on the available date. • Best Date - There are two possible streams of actions that the Allocation mechanism suggests in the case of a delay. One set of recommendations is on the supply side (Best Date based) and the other recommendation set is on the demand side (Available Date based). The best date is the date on which the ship set / forecast can be allocated if the user chooses the component level pull-in and push-out recommendations wherever applicable. Essentially, the system tries to pull-in supply if it encounters a delay. This is reflected through the best date at the component level. It should be noted that the system recommends a pull-in only to the extent feasible based on lead-time considerations. Push-outs are recommended by the system in the case of STO's and WIP's based on infeasibility. This will be explained in greater detail in the section on WIP's and STO's. o In a subsequent drilldown, we provide the best dates at all the component levels. Theoretically, the best date of all components could be built up to provide the best date at this level. o Also, it should be noted that the best date would be different from the required date only if the user chose "Reconcile Delay" as the delay policy. Else, partial allocation or no allocation would result in the best date and the required date being the same. Shortage Policies have no bearing on the best date. • Delay - This is the number of days the order has been delayed. This can be calculated as "Min (0, Available Date - Schedule Date)". • Past Due Supply - This will be a flag that will be set to Y / N depending on whether the order has any supply that is past due allocated to it. Essentially, any supply, ex.
PO that has a Schedule Date prior to the system date is rolled forward to the system date in the SDM mechanism as available supply. Although, this is a valid assumption, the user still wants to know if an order contains a supply of this kind because it is dubious supply. Hence, this flag will help determine this. • Revenue - This is the original revenue of the Ship set / Sales Order. In the case of sales_order, this should be picked up from Total_selling_price from sales_ft. In the case of a forecast, this should be computed as "ASP (PCB)*Current Qty (Forecast_ft)".
17 • Cost - This is the original cost associated with the ship set / Forecast. In the case of a forecast, it is Current Value (from forecast_ft). In the case of a ship set, this should be cost (Sales_ft)* (Ordered Qty - Shipped Qty - Cancelled Qty). • Margin - This should be computed as "Revenue - Cost" • Risk - Risk is basically the $ value part of the revenue that is associated with any problem (Short / Delay / Partial / No Allocation). This would provide an indication to the user about the enormity of the problem. Hence, the Order Management personnel could prioritize solving the high-risk orders ahead of the low risk orders. o Assumption: The assumption that we make is that the same discount percentages that were applicable to the sales order are applicable in the same proportion to the modified order. o Risk = [{(Total Original Selling Price) (What-if Quantity / Original
Quantity)}- {(Total Original Selling Price / Original Quantity) Allocated Quantity }]. Allocated Quantity is the quantity that is allocated without a delay or short problem. If what-if quantity is not filled in, what-if quantity = original quantity. • Cancel-by-date - This is the date on which the order might get cancelled if it is not shipped. Referring to Figures 18 and 19, an Order Summary Drilldown Overview is illustrated. The view described in the previous section helps the order fulfillment manager obtain a high level view of all orders that have a problem associated with it and its financial impact. However, in order to solve a problem and effectively use the SDM module, it becomes necessary for the manager to drill down further and study the problems and resolutions. There are three drilldowns that are row drilldowns that are presented to the user. They are 1) Order Line Drilldown, 2) Problem Parts Drilldown and 3) Buildable Supply Drilldown. Dimensions Passing - In all these drilldowns all the dimensions in the parent view are passed down to the child view. It should be noted though that the best-date at the order-level view and the best date at the part-level views should not be mapped. Similarly, the other- dates. This drilldown view allows a user to bring up the line details on the Order of Ship set and Forecast. This is a row level drilldown. This will give the user a sense of how the individual lines have been allocated, its financial impact and the associated problems. This view is at the line level. The various details are as follows. • Order Ship set Number - This is the Order ship set number for the line
18 Line Number - This indicates the line number Customer - This is the customer for the order Order Type - This is the order type for the order Demand Type - This is the demand type for the order Held For - This will be the Site for which the sales Order is Originally Held for. Order Site - This will be the demanding site Supply Site - This will be the supplying site Parts - This is the end-item assembly name of the line • Part Description - This is the description associated with the part Scheduled Ship Date - This is the scheduled ship-date for the order. At the line level, the scheduled ship date is the same as the order level. This should be picked up from the schedule_ship_date in ft_sales or dt_sales_order_shipset? In the case of a forecast, the forecast-date (start or end-date of the period based on what is populated in forecast_ft will be used) Available Date -There are two possible streams of actions that the Allocation mechanism suggests in the case of a delay. One set of recommendations is on the supply side (Best Date based) and the other recommendation set is on the demand side (Available Date based). Thus the available date is the date on which the individual line will be available given the current state of supply. Theoretically, the available date of all components could be built up to provide the available date at this level. There is just one caveat to the calculation of available dates. In the case of on-hand, In-Transit and PO as supply, the available dates are simply defined as system dates, in-transit dates and PO dates respectively. However, in the case of a WIP and an STO, the available date at this level is constructed with the feasible available dates. Also, it should be noted that the available date would be different from the required date only if the user chose "Reconcile Delay" as the delay policy. Else, partial allocation or no allocation would result in the available date and the required date being the same. Shortage Policies have no bearing on the available date. • Customer Request Date - This is the CRD for the Order • Cancel by Date - This is the cancel by date for the Order • Best Date - There are two possible streams of actions that the Allocation mechanism suggests in the case of a delay. One set of recommendations is on the supply side
19 (Best Date based) and the other recommendation set is on the demand side (Available Date based). The best date is the date on which the line can be allocated if the user chooses the component level pull-in and push-out recommendations wherever applicable. Essentially, the system tries to pull-in supply if it encounters a delay. This is reflected through the best date at the component level. It should be noted that the system recommends a pull-in only to the extent feasible based on lead-time considerations. Push-outs are recommended by the system in the case of STO's and WIP's based on infeasibility. This will be explained in greater detail in the section on WIP's and STO's. Theoretically, the best date of all components could be built up to provide the best date at this level. Also, it should be noted that the best date would be different from the required date only if the user chose "Reconcile Delay" as the delay policy. Else, partial allocation or no allocation would result in the best date and the required date being the same. Shortage Policies have no bearing on the best date. There is only one reason why the system would compute best date, different from the available date at the component level: Delay Resolution - In the event that the available date > required date, the system would try to provide a best date so that supply can be pulled-in. However, it should be noted that the best date recommendation would honor lead-times. It should be noted that best dates are not computed if there exists no delay. In other words, the system would never try to expedite if the available state of supply can meet the order on time. (Even if the available date has some slack). Critical path indicates the line that is delayed the most. The line where the delay (available date - schedule date) is maximum is set to "Y". However, it should be noted that all lines are set to N when there is no delay in any of the lines.
Delay is the number of days the order has been delayed. This can be calculated as "Min (0, Available Date - Schedule Date)". Requested Quantity - This is the demand quantity used while allocating this demand. This is carried forward from the "Allocation Quantity" in the inputs. Allocated Quantity - This represents that portion of the requested quantity for which supply was allocated. This could be different from the requested quantity only if the user chose "Partial" / "Ship Only Complete" on the Shortage Policy or "Partial / Ship Only Complete" on the delay policy. Drill to Problem Parts Referring to Figure 20, this drilldown view essentially brings up the details of the supply that were used in the allocation of the selected Order: Ship set / Forecast. In addition, this view shows only those supplies that have an action that is not of the type "None" (Explained later) associated with it. All supply that has an action type of "None" gets
20 automatically put into the drilldown buildable supply. The view contains the entire supply associated with the chosen ship set and is not specific to any line. The various details are: Supply Id - This details the id associated with the supply. In the case of an existing supply, this is the id of the supply. PO - PO Header.Po Line STO - STO Header.STO Line ASN - STO Header. STO Line. ASN No (This is the associated STO) WIP - Work Order Number On-Hand - Blank WIP Requirement - WIP id (However, the supply type column would say WIP
Requirement) For all Recommended Supply (new), system generated IDs are provided. Parts - This provides the name of the part associated with the supply Part Description - This is the description associated with the part Within Lead Time - This indicates if the delay problem (if it is a delay problem) can be solved by the recommendation. This flag is hence set to Y if the best date is earlier than the required date. Else it is set to N Action - These are the set of supply that has a required set of actions associated with them. The various types of actions are as follows: New - This action is recommended if there is a new recommended supply. This could be a new PO, a new STO or a new WIP, depending on whether the recommendation is provided for a buy, transfer or a make part. This action is taken to solve a shortage problem (Make, Buy and Transfer Parts). Thus, by creating a new supply (PO's) or a new execution statement (STO's or WIP's), the problems are solved. This action could however not solve a delay problem. However, the system issues new supply as early as it can to meet the order. (Not earlier than required though). However, this supply could still result in a situation where the Available Date = best date > required date. In this case, nothing can be done to mitigate the delay problem. Pull - For existing supply (WIP / PO / STO), if Available date > best date and Available Date > required date, a pull-in is recommended. This action is taken in order to solve the delay problem. The recommended action indicates to the user that supply must be pulled in from the available date to the best date.
21 However, as in the previous case, it is quite possible that the delay problem cannot be completely solved. This is indicated by the condition where Best Date > Required Date Push-out - Based on feasibility, a push out is recommended for WIP's and STO's if Feasible available date > Available Date. Push-outs are recommended only to account for feasibility. This is explained in great detail on the sections on WIP's and In-Transits. Also, consistent with the previous actions, a push out could result in a delay whereby the Best Date > Required Date No-Action - This is a case where no action is recommended in-spite of a delay problem. Thus, this action happens when Best Date >= Available Date > Required Date This is possible for all six supply types - WIP's, On-Hands, STO's, PO's, In-Transit and WIP Requirement Note: Combination of Actions. It is quite possible to have a combination of actions. For example, it is quite possible that you have a "new" PO where you can have a "No Action" also applicable. However, the rule that we apply here is that the Order in which the actions are stamped are in the priority of "New" > "Pull-in" > "Push-Out" > "No- Action" > "None" Supply Type - This column indicates the various supply types associated with the supply. They could be one of the following, WIP, On-Hand, WIP-Requirement. (Refers to the issued qty against the WLP), PO, STO, ASN, NEWWIP, NEWPO, NEWSTO, or other supply type. Held at - This is the site where the supply is Held at or received at (for PO's / STO's /
ASN) as applicable. Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO / STO / ASN). For all other supply sources, this should be N / A Required Date - This is the date on which the supply is required to ensure that this order is delivered on time. The required date at each level is computed by blowing down from the scheduled date at the order: ship set / forecast level.
22 Available Date - This is the date on which the supply is available given the current state. (This is derived from the input dates associated with the supply. Theoretically, the available date of all components could be used to provide the available date at the order: ship set / forecast level. There is just one caveat to the calculation of available dates. In the case of on-hand, In-Transit and PO as supply, the available dates are simply defined as system dates, in-transit dates and PO dates respectively. However, in the case of a WIP and an STO, the available date at this level is constructed with the feasible available dates. Feasible Available Date - This would be different in the case of only an STO / WIP based on feasibility. In short, if lower level components required for the execution of a WIP (WIP Requirements) or an STO is not available to meet the system provided available date of the WIP / STO, then a feasible available date would be computed. This would be based on the supply availability of the lower requirements. Details on this computation are provided in the WIP / STO sections. In all other supply types, the feasible available date would be equal to the available date. Best Date - This is the date on which supply can be best procured. The best date at the component levels could all be built up to construct the best date at the order: ship set / forecast level. There is only one reason why the system would compute best date, different from the available date: Delay Resolution - In the event that the available date > required date, the system would try to provide a best date so that supply can be pulled-in. However, it should be noted that the best date recommendation would honor lead-times. It should be noted that best dates are not computed if there exists no delay. In other words, the system would never try to expedite if the available state of supply can meet the order on time. (Even if the available date has some slack) Supply Quantity - This is the quantity associated with the supply-id. This is the whole quantity. This is derived from the inputs and the details specific to the computation for each supply type can be found in the section "View and Edit Supply Details". Allocated Quantity - This is the quantity of the supply that is allocated to the order: ship set / forecast. Past Due Supply - This will be a flag that will be set to Y / N depending on whether the supply is past due or contains any past due supply (for a WIP that contains a past due PO). Essentially, any supply, ex. PO that has a Schedule Date prior to the system date is rolled forward to the system date in the SDM mechanism as available supply. Although, this
23 is a valid assumption, the user still wants to identify this dubious supply. Hence, this flag will help determine this. Lead Time - This is the lead-time required for that supply. This is primarily the lead- time that is used in SDM. For a make part, this is manufacturing lead-time. This should be found in the PCB. For a buy part, this is procurement lead-time and again found in PCB. For a transfer part, this is the transfer lead-time Drill to Buildable Supply Referring to Figure 21, this view basically details all those supply that have an action "None" associated with them. Essentially, what this means is that this supply does not cause any problem to the order and need not be bothered with w.r.t allocation to these orders. The various field are explained below. • Supply Id - This details the id associated with the supply. In the case of an existing supply, this is the id of the supply. PO - PO Header.Po Line STO - STO Header.STO Line ASN - STO Header. STO Line. ASN No (This is the associated STO) WIP - Work Order Number On-Hand - Blank WIP Requirement - WIP id (However, the supply type column would say WIP Requirement) Parts - This provides the name of the part associated with the supply Part Description - This is the description associated with the part Supply Type - This column indicates the various supply types associated with the supply. They could be one of the following: WIP, On-Hand, WIP -Requirement. (Refers to the issued qty against the WIP), PO, STO, ASN, or other type. Held at - This is the site where the supply is Held at or received at (for PO's / STO's / ASN) as applicable. Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO /
STO / ASN). For all other supply sources, this should be N / A. Available Date - This is the date on which the supply is available given the current state. (This is derived from the input dates associated with the supply.
24 Theoretically, the available date of all components could be used to provide the available date at the order: ship set / forecast level. There is just one caveat to the calculation of available dates. In the case of on-hand, In-Transit and PO as supply, the available dates are simply defined as system dates, in-transit dates and PO dates respectively. However, in the case of a WIP and an STO, the available date at this level is constructed with the feasible available dates. Supply Quantity - This is the quantity associated with the supply-id. This is the whole quantity. This is derived from the inputs and the details specific to the computation for each supply type can be found in the section "View and Edit Supply Details". Allocated Quantity - This is the quantity of the supply that is allocated to the order: ship set / forecast. Past Due Supply - This will be a flag that will be set to Y / N depending on whether the supply is past due or contains any past due supply (for a WIP that contains a past due PO). Essentially, any supply, ex. PO that has a Schedule Date prior to the system date is rolled forward to the system date in the SDM mechanism as available supply. Although, this is a valid assumption, the user still wants to identify this dubious supply. Hence, this flag will help determine this. Scenario 2 - Parts Summary This view is an alternate view of looking at the results from the allocation. This basically enables a commodity manager to look at all components aggregated across all Order Allocations. This is the flow structure for these views. Referring to Figure 22, a drill down view is illustrated of a first level view is a view that provides the user the aggregate view of all components at the part / action / supply-type / held-at / supply-site level. This means that all unique combinations of the above dimensions will be represented as unique rows. The second level drilldown- view provides the user the ability to look at all the supply-ids of those parts that have the parent dimensional combinations. Essentially, when drilling down all dimensions in the parent view are passed. In any view, the uniqueness of a row is determined by the combination of dimensions defined in the view. The third drilldown takes the user to the list of orders that have the chosen supply id in their allocation. The fourth level drilldowns are similar to the drilldowns in the order summary. Parameters - Input The input parameters for this will be the following:
25 1) Allocation Name - This refers to the name of the SDM Simulation. We should not show any other type of simulation in this drop-box. 2) Product families - This refers to the product family of the components and assemblies for the end-assembly. This includes the product family of the end-assembly too 3) Commodity codes - This refers to the commodity codes of the components and assemblies for the end-assembly. This includes the commodity codes of the end-assembly too 4) Parts - This is the parts (component / assembly / end assembly) that the user wants to see 5) Part Type - Parts could be either make / buy / transfer parts 6) Held at - This is the site at which the supply is held-at. (Received at) if it is a
PO / STO. Note: Although the user has already chosen their input criteria in the allocation, this parameter constraint allows the user to look at only the outputs that he/she is interested in for one particular analysis. It is quite possible that different users (ex. Commodity Managers), looking at their own portfolio of Supply would like to see only those supplies that they manage. Parts Summary View Referring to Figure 23, a parts summary view is illustrated. As explained in the above section, the first level view is a view that provides the user the aggregate view of all components at the part / action / supply-type / held-at / supply-site level. This means that all unique combinations of the above dimensions will be represented as unique rows. The description of the various columns is presented below. Parts provide the name of the part associated with the supply. Part Description is a description identifier for the part. Action defines the action associated with the part. New - This action is recommended if there is a new recommended supply. This could be a new PO, a new STO or a new WIP, depending on whether the recommendation is provided for a buy, transfer or a make part. This action is taken to solve a shortage problem (Make, Buy and Transfer Parts).
Thus, by creating a new supply (PO's) or a new execution statement (STO's or WIP's), the problems are solved. This action could however not solve a delay problem. However, the system issues new supply as early as it can to meet the order. (Not earlier than required though). However, this supply could still result in a situation where the Available Date = best date > required date. In this case, nothing can be done to mitigate the delay problem.
26 Pull - For existing supply (WIP / PO / STO), if Available date > best date and Available Date > required date, a pull-in is recommended. This action is taken in order to solve the delay problem. The recommended action indicates to the user that supply must be pulled in from the available date to the best date. However, as in the previous case, it is quite possible that the delay problem cannot be completely solved. This is indicated by the condition where Best Date > Required Date Push-out - Based on feasibility, a push out is recommended for WIP's and STO's if Feasible available date > Available Date. Push-outs are recommended only to account for feasibility. Also, consistent with the previous actions, a push out could result in a delay whereby the Best Date > Required Date No- Action - This is a case where no action is recommended in-spite of a delay problem. Thus, this action happens when Best Date >= Available Date > Required Date This is possible for all six supply types - WIP's, On-Hands, STO's, PO's, In-Transit and WIP Requirement None - this means is that this supply does not cause any problem to the order and need not be bothered with w.r.t allocation to the orders. Note: Combination of Actions. It is quite possible to have a combination of actions.
For example, it is quite possible that you have a "new" PO where you can have a "No Action" also applicable. However, the rule that we apply here is that the Order in which the actions are stamped are in the priority of "New" > "Pull-in" > "Push-Out" > "No- Action" > "None". Part Type - A Part could be either a make, buy or a transfer part and this property is defined in PCB in addition to the appropriate linkages in BOM / BOD tables. Care should be noted that this attribute is fed consistent with the BOM / BOD table. Supply Type - This column indicates the various supply types associated with the supply. They could be one of the following, WIP, On-Hand, WIP-Requirement. (Refers to the issued qty against the WIP), PO, STO, ASN, NEWWIP, NEWPO, and NEWSTO. Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO / STO / ASN). For all other supply sources, this should be N / A.
27 Allocated Quantity - This is the quantity of the supply that is allocated to the order: ship set / forecast. Lead Time - This is the lead-time required for that part. This is primarily the lead- time that is used in SDM. For a make part, this is manufacturing lead-time. This should be found in the PCB.
For a buy part, this is procurement lead-time and again found in PCB. For a transfer part, this is the transfer lead-time. Where is this found? Referring to Figure 24, Parts Summary Drilldown Overview is illustrated. The view described in the previous section helps the commodity manager obtain a high level view of all parts that have a problem associated with it and its financial impact. However, in order to solve a problem and effectively use the SDM module, it becomes necessary for the manager to drill down further and study the problems and resolutions. The drill down structure is pictorially represented in Figure 24. The first level view is a view that provides the user the aggregate view of all components at the part / action / supply-type / held-at / supply-site level. This means that all unique combinations of the above dimensions will be represented as unique rows. The second level drilldown- view provides the user the ability to look at all the supply-ids of those parts that have the parent dimensional combinations. Essentially, when drilling down all dimensions in the parent view are passed. In any view, the uniqueness of a row is determined by the combination of dimensions defined in the view. The third drilldown takes the user to the list of orders that have the chosen supply id in their allocation. The fourth level drilldowns are similar to the drilldowns in the order summary. Dimensions Passing - In all these drilldowns all the dimensions in the parent view are passed down to the child view. It should be noted though that the best-date at the order-level view and the best date at the part-level views should not be mapped. Similarly, the other-dates. There is one exception to this - In the drilldown from Order Summary to its two component level drilldowns, the components that would show up will be constrained only by its parent order no and not by its super parent view dimensions. Drill to Problem Details Referring to Figure 25, drill down details are illustrated. The various columns in this view are explained. It should be noted that this view is fundamentally different from the part level views that can be drilled down from the order summary view because, this does not represent supply specific to a particular order. The various columns are explained as follows:
28 Supply Id - This details the id associated with the supply. In the case of an existing supply, this is the id of the supply. PO - PO Header.Po Line STO - STO Header.STO Line ASN - STO Header. STO Line. ASN No (This is the associated STO) WIP - Work Order Number On-Hand - Blank WIP Requirement - WIP id (However, the supply type column would say WIP Requirement) For all Recommended Supply (new), system generated id's are provided. Held For - This will be the Site for which the supply-id is Originally Held for. (If we have the ignore held for flag turned to Y, this should be left blank) Supply Type - This column indicates the various supply types associated with the supply. See above. Held at - This is the site where the supply is Held at or received at (for PO's / STO's
ASN) as applicable. Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO / STO / ASN). For all other supply sources, this should be N / A. Earliest Required Date - This is the date on which the supply is required to ensure that all the orders to which it has been allocated to is delivered on time. Available Date - This is the date on which the supply is available given the current state. (This is derived from the input dates associated with the supply. Feasible Available Date - This would be different in the case of only an STO / WIP based on feasibility. In short, if lower level components required for the execution of a WIP (WIP Requirements) or an STO is not available to meet the system provided available date of the WIP / STO, then a feasible available date would be computed. This would be based on the supply availability of the lower requirements. Details on this computation are provided in the WIP / STO sections. In all other supply types, the feasible available date would be equal to the available date. Best Date - This is the date on which supply can be best procured. If the supply is broken-up, (for example if a PO is split (based on splittable flag, explained later), there could be multiple instances / rows of the same Supply-id.
29 One reason why the system would compute best date, different from the available date: Delay Resolution - In the event that the available date > required date, the system would try to provide a best date so that supply can be pulled-in. However, it should be noted that the best date recommendation would honor lead-times. It should be noted that best dates are not computed if there exists no delay. In other words, the system would never try to expedite if the available state of supply can meet the order on time. (Even if the available date has some slack) Supply Quantity - This is the quantity associated with the supply-id. This is the whole quantity. This is derived from the inputs and the details specific to the computation for each supply type can be found in the section "View and Edit Supply Details". Allocated Quantity - This is the quantity of the supply that is allocated to the order: ship set / forecast, Revenue Impact - This is the sum of the revenue associated with all the unique orders to which this row combination (dimension combinations) has been allocated. Drill to Affected Orders This drilldown will take the user to the same view as the problem order summary view. However, when we drill to this view, the list of orders that would come up would be the list of impacted orders due to the relevant supply id. For each of these order.shipset, three drilldown similar to the previous scenario will exist. Scenario 3 - Supply Details Referring to Figure 26, this view is similar to the previous view. However, this view directly goes to the supply details level. The drilldown structure from there on and the views would however be similar to the drilldown structure in the previous views. However, the initial view would be different from the view provided in the previous view. The first level view provides the user the ability to look at all the supply-ids that are used in the allocation. In any view, the uniqueness of a row is determined by the combination of dimensions defined in the view. The second-level drilldown view takes the user to the list of orders that have the chosen (supply id, action and supply type) in their allocation. (Dimensions that should be passed) The third-level drilldowns are similar to the drilldowns in the order summary. The input parameters are exactly similar to the ones in the previous view.
30 Supply Details View Parameters - Input The input parameters for this will be the following: 1) Allocation Name - This refers to the name of the SDM Simulation. We should not show any other type of simulation in this drop-box. 2) Product families - This refers to the product family of the components and assemblies for the end-assembly. This includes the product family of the end-assembly too 3) Commodity codes - This refers to the commodity codes of the components and assemblies for the end-assembly. This includes the commodity codes of the end-assembly too 4) Parts - This is the parts (component / assembly / end assembly) that the user wants to see 5) Part Type - Parts could be either make / buy / transfer parts 6) Supply Type - This indicates what is the type of Supply (WIP / PO etc.) 7) Held at - This is the site at which the supply is held-at. (Received at) if it is a PO / STO. 8) Start Date & End Date - This is start date and end date (based on the original available date of the supply ) Note: Although the user has already chosen their input criteria in the allocation, this parameter constraint allows the user to look at only the outputs that he/she is interested in for one particular analysis. It is quite possible that different users (ex. Commodity Managers), looking at their own portfolio of Supply would like to see only those supplies that they manage. Referring to Figure 27, the various columns in this view are explained. It should be noted that this view is fundamentally different from the part level views that can be drilled down from the order summary view because, this does not represent supply specific to a particular order. Supply Id - This details the id associated with the supply. In the case of an existing supply, this is the id of the supply. PO - PO Header.Po Line STO - STO Header.STO Line ASN - STO Header. STO Line. ASN No (This is the associated STO) WIP - Work Order Number On-Hand - Blank
31 WIP Requirement - WIP id (However, the supply type column would say WIP Requirement) For all Recommended Supply (new), system generated id's are provided. Parts - This provides the name of the part associated with the supply Part Description - This is a description identifier for the part. Action - This defines the action associated with the part. New - This action is recommended if there is a new recommended supply. This could be a new PO, a new STO or a new WIP, depending on whether the recommendation is provided for a buy, transfer or a make part. This action is taken to solve a shortage problem (Make, Buy and Transfer Parts).
Thus, by creating a new supply (PO's) or a new execution statement (STO's or WIP's), the problems are solved. This action could however not solve a delay problem. However, the system issues new supply as early as it can to meet the order. (Not earlier than required though). However, this supply could still result in a situation where the Available Date = best date > required date. In this case, nothing can be done to mitigate the delay problem. Pull - For existing supply (WEP / PO / STO), if Available date > best date and Available Date > required date, a pull-in is recommended. This action is taken in order to solve the delay problem. The recommended action indicates to the user that supply must be pulled in from the available date to the best date. However, as in the previous case, it is quite possible that the delay problem cannot be completely solved. This is indicated by the condition where Best Date > Required Date Push-out - Based on feasibility, a push out is recommended for WIP's and STO's if Feasible available date > Available Date. Push-outs are recommended only to account for feasibility. This is explained in great detail on the sections on WIP's and In-Transits. Also, consistent with the previous actions, a push out could result in a delay whereby the Best Date > Required Date No-Action - This is a case where no action is recommended in-spite of a delay problem. Thus, this action happens when Best Date >= Available Date > Required Date
32 This is possible for all six supply types - WIP's, On-Hands, STO's, PO's, In-Transit and WIP Requirement None - this means is that this supply does not cause any problem to the order and need not be bothered with w.r.t allocation to the orders. Note: Combination of Actions. It is quite possible to have a combination of actions.
For example, it is quite possible that you have a "new" PO where you can have a "No Action" also applicable. However, the rule that we apply here is that the Order in which the actions are stamped are in the priority of "New" > "Pull-in" > "Push-Out" > "No-Action" > "None" Supply Type - This column indicates the various supply types associated with the supply. See above. Part Type - A Part could be either a make, buy or a transfer part and this property is defined in PCB in addition to the appropriate linkages in BOM / BOD tables. Care should be noted that this attribute is fed consistent with the BOM / BOD table. Held For - This will be the Site for which the supply-id is Originally Held for. (If we have the ignore held for flag turned to Y, this should be left blank) Held at - This is the site where the supply is Held at or received at (for PO's / STO's / ASN) as applicable. Stockroom - This is the stockroom where the supply is held. For all the supply types other than on-hand, this would be N / A Supply Site - This is the site from where the supply is received (in the case of a PO / STO / ASN). For all other supply sources, this should be N / A. Earliest Required Date - This is the date on which the supply is required to ensure that all the orders to which it has been allocated to is delivered on time. Available Date - This is the date on which the supply is available given the current state. (This is derived from the input dates associated with the supply. Feasible Available Date - This would be different in the case of only an STO / WIP based on feasibility. In short, if lower level components required for the execution of a WIP (WD? Requirements) or an STO is not available to meet the system provided available date of the W P / STO, then a feasible available date would be computed. This would be based on the supply availability of the lower requirements. Details on this computation are provided in the WIP / STO sections. In all other supply types, the feasible available date would be equal to the available date.
33 Best Date - This is the date on which supply can be best procured. If the supply is broken-up, (for example if a PO is split (based on splittable flag, explained later), there could be multiple instances / rows of the same Supply-id. One reason why the system would compute best date, different from the available date: Delay Resolution - In the event that the available date > required date, the system would try to provide a best date so that supply can be pulled-in. However, it should be noted that the best date recommendation would honor lead-times. It should be noted that best dates are not computed if there exists no delay. In other words, the system would never try to expedite if the available state of supply can meet the order on time. (Even if the available date has some slack). Supply Quantity - This is the quantity associated with the supply-id. This is the whole quantity. This is derived from the inputs and the details specific to the computation for each supply type can be found in the section "View and Edit Supply Details". Allocated Quantity - This is the quantity of the supply that is allocated to the order: ship set / forecast. Revenue Impact - This is the sum of the revenue associated with all the unique orders to which this row combination (dimension combinations) has been allocated. Order Ship set Number - This is the Order Ship set Number where the supply is used Line Number - This is the line number where the supply is used Line Part Name - This is the line part where the supply is used Line Part Description - This is the line part description Drill to Affected Orders This drilldown will take the user to the same view as the problem order summary view. However, when we drill to this view, the list of orders that would come up would be the list of impacted orders due to the relevant supply id. For each of these order.shipset, three drilldowns similar to the previous scenario are performed. The Supply Demand the basics of a Supply Chain Execution Application and identify how the SDM Module should be modeled in this regard. Figure 28 illustrates the manner in which a typical company operates. A constrained Supply Plan is developed using a supply Planning Application. However, when orders do not actualize similar to the envisioned forecast, fulfillment becomes an issue. In addition, supply situations that were assumed might not be valid anymore. SDM helps manage execution in this kind of a disruptive environment. Hence, SDM can be thought of as a Supply Chain Execution System that helps companies manage their fulfillment process in the midst of unforeseen supply and demand changes.
34 There may be multiple aspects to an intelligent execution system: Exception Monitoring, Resolution to Exception and Tie Back to the Execution System (not part of current SDM scope). Shortage Reporting and Delay reporting based on available state of supply can be thought of as exception monitoring. Resolution to Exceptions include various Order specific recommendations around additional material procurement, expedites of parts of WIP's etc. These actions need to satisfy fulfillment objectives. (Ex. Achieved by the Algorithm). They need to Cause Minimum Disruptions to the Current Planned Execution. (Ex. Use Existing WIP's). Actionable Execution Statements that respect certain rules (Ex. EOQ, Order Modifiers, Aggregation of Recommendations etc.). Thus, the basic philosophy of SDM is that it helps resolve the order fulfillment process through recommending changes to the available supply. This approach is fundamentally very different from planning systems that tend to be more disruptive and do a complete re-planning. SDM Functional Details Viewed in a simplistic fashion, SDM does the following functions. It ranks the Demand, it Allocates Supply to Demand in an order of rank in an n-tiered environment,
Applies (User Driven) Shortage and Delay Policies.Aggregate Supply for lot-sizing (similar) purposes. In order to achieve this, the user chooses the demand (ranked manner) and supply. In addition the user chooses the shortage and delay policies to be applied. The results of the SDM module provides both supply and demand messages that help the user in changing the execution to better the order management scenario. The following sections describe in great detail the functional elements. Ranking Strategy, WIP & In-Transit Allocation, N-tier considerations. Ranking Strategy Functionality Functionality Description: This feature is part of the allocation feature. Given that executing this part of the allocation process takes time, parts of the computation (range computation) are pre-computed earlier during the ETL run. Ranking Strategies are basically strategies used to prioritize orders in the order of their importance. This order / rank will thus determine the order in which the orders receive supply. The user can define the ranking strategies based on two different strategies: Weighted (Weight) & Ordered-By (Order). Weighted Strategy Referring to Figure 29, a chart is shown of a sample for creating weighted values for Ranking Strategies: Orders are ranked based on a score that is computed for each order. "N" strategies can be defined as a list of strategies. One of them is marked as default to be initially displayed in the allocation module. The various parameters that are used to compute this
35 score will include the following attributes of the order / Forecast. They include: Customer, Schedule Date, B ooked Date, Promise Date, Cancelled Date, Customer Requested Date, Demand Type (Attribute of SO and Forecast), Order Type (Attribute of SO and Forecast), Ship set Revenue, and Ship set Gross Margin. These should be extended to attributes that any other business model will use. The user has the ability to provide different weights to each of these attributes. Each unique selection will constitute a ranking strategy. The score for every order will be computed by computing these weights. Since every attribute is a different dimension, these attributes are normalized with respect to each other. In another embodiment, each attribute is normalized with respect to its own range of maximum and minimum values, in order to compute the score. (The normalization method will be described in the Score Computation section of the document). The range for these attributes (used during normalization are set during every ETL run. The various priorities within each attribute can be sourced from a source system when they are non-quantitative attributes. Also, the priorities for non-quantitative attributes are system level and are not specific to any particular strategy. Tie-Break: While ranking the orders if the scores are the same, we break the ties first with schedule date. Beyond that, we can rank the orders in a random fashion. Weight / Score Computation Every ship-set will be associated with a particular score and when the user in the allocation module chooses a set of ship sets, it will be ranked / ordered according to the score that has been pre-computed. There are two distinct entities that serve as demand - Forecasts / Sales Orders. Customer, Order Type, Demand Type etc. will have numerical priorities associated that can be defined for every instance of the same (in order type_dt and customer_dt etc.) An example will illustrate better how scores can be computed for sales orders / forecasts. Ordered-By Ranking Strategy Creating Ranking Strategies: • Orders are ranked based on a sorted basis. • "N" strategies can be defined as a list of strategies. One of them is marked as default to be initially displayed in the allocation module. • The various parameters that are used to compute this score will include the following attributes of the order / Forecast. o Customer
36 o Schedule Date o Booked Date o Promise Date o Cancelled Date o Customer Requested Date o Demand Type (Attribute of SO and Forecast) o Order Type (Attribute of SO and Forecast) o Ship set Revenue o Ship set Gross Margin These should be extended to attributes that any other business model will use. The user has the ability to provide different priorities to each of these attributes. Each unique selection will constitute a ranking strategy. The various priorities within each attribute can be sourced from a source system when they are non-quantitative attributes. Also, the priorities for non-quantitative attributes are system level and are not specific to any particular strategy. Tie-Break: While ranking the orders if the scores are the same, we break the ties first with schedule date. Beyond that, we can rank the orders in a random fashion. Order Computation • All ship sets are ranked through a prioritization scheme • There are two distinct entities that serve as demand - Forecasts / Sales Orders. • Different attributes of a ship set are given different priorities. • All Ship sets are sorted based on the attribute with the first priority • Now, all ship sets within the same block of the first priority is further sorted among themselves based on the second priority attribute. • This extends till all prioritized attributes that are covered in the strategy are sorted.
Example: Sales Order Attributes: Schedule Date, Revenue & Customer. Strategy Schedule Date - 1 Revenue — 2 Customer - 3 IBM - 1 Dell - 2 Data
37 Sales Order A - Schedule Date: Jan, Revenue: lOMillion, Customer Dell Sales Order B- Schedule Date: Feb, Revenue: 15Million, Customer IBM Sales Order C- Schedule Date: Feb, Revenue: 10 Million, Customer Dell Sales Order D- Schedule Date: Feb, Revenue: 10 Million, Customer IBM Working 1) The earliest schedule date is Jan. Hence; the first order to be selected is Sales Order A. Since every other order's scheduled date is the same, the ranking continues. 2) The next attribute is Revenue. Sales Order B gets picked up since Sales Order B has the highest revenue among sales Order B; Sales Order C & Sales Order D. Hence Sales Order B gets selected. Since, the revenues of Sales Order C & Sales Order D are the same, the ranking continues. 3) Customer is a non-quantitative attribute. Hence, the various elements have been individually ranked. For example, IBM is ranked ahead of Dell in this example. Hence, Sales Order C is ahead of Sales Order D. 4) Hence, the final ranking is Sales Order A, Sales Order B, Sales Order C and
Sales Order D.
Defining Ranking Strategies The user can define the ranking strategy through the UI. There are two distinct user interactions, defining Ranking Strategies and Managing Strategies. The define-ranking strategy page helps the user define the individual strategies. The two types of strategies can be defined by clicking on the appropriate radio button. All the attributes are listed. The user can enter the weights or the priorities as the case may be. Once defined, this strategy should show immediately (or after next ETL? Run). The screen-shots representing the two strategies are attached below. Referring to Figure 30 and 31 these pages, the user has the ability to update or delete the ranking strategies. Clicking on the strategy name should take the user to the define strategy page for that strategy. Hence, the user should be able to update the strategy. The picture is attached below.
WIP Functionality Referring to Figure 32, a WTP page is illustrated. In an ERP system, when WIP's are issued, a corresponding WIP requirement is issued on the lower level assemblies so that this
WLP can be manufactured. There are two ways in which various environments handle this
WIP Requirement
38 Option 1 : Released WIP - A WIP is nothing but a statement of execution to convert a basket of components into an assembly. A WLP is thus issued with a projected completed date and a quantity. Associated with a WIP is a set of WIP Requirements that constitutes the set of lower level BOM components (basket of components that make up the assembly). At any point in time, some of this WIP Requirement might have been issued to the WJJP and some might not. Also, some parts of the WIP might have been additionally been received as final assembly and thus be part of the assembly inventory pool. Hence, while looking at WIP's as a source of Supply, the system needs to accomplish the following things. It must ensure that the WJJP (or the part of the WJP that is used) will be feasible. In other words, allocate material to their WJP Requirements. It must allocate additional material to a WJP only if used by an actual order or sales forecast. And, it should not use the issued material to any WJP for any other WJJP. Option 2: Locked WJP: In addition to the fact that WJP Requirements have been partially or completely issued at the lower levels, these are WJP's that the shop floor has locked and hence these WIP's take precedence even over Orders. This is because the WJP's have been planned tightly and the shop floor does not have the ability to react so quickly in order that this WJP be cancelled. Hence, material must first be allocated to satisfy these WIP's first. These WJP's must then be used as a source of supply through Option 1. (This will hence be a pre-processing step similar to how the SDM allocates supply to Orders). However, in these WIP's all the WJP Requirement required would have already been issued through the pre-processing step. Mechanism for WJP's: Allocation 1) Allocate in the order of ship set priority 2) Arrange Supply in an order of "Issued Qty against WJP Requirements", ASN's, On-Hand, WJP's and PO's in the earliest available order. (This order should be driven off a system parameter and currently this should be the default order). In addition as in 2.1 continue to allocate non-short supply before short supply across the board. 3) If we allocate WIP's, allocate them with Feasible Available Date 4) In order to find the feasible available date, a. The Required Qty is the requirement at that node, b. In Order to compute the Feasible Available Date, i. Treat the WTP as a demand source, ii. Allocate to this WTP as we would allocate to a ship-set.
39 iii. However, we must first use the (un-used)* issued material in the WTP
Requirement before we consider any other sources of supply (same order as above) iv. Obtain the Feasible Available Date for the WTP based on the availability of the allocated lower-level supply. v. The Best possible Date is constructed as in every other supply situation with the best possible date at the lower levels c. Decrement the Supply used from the Supply Manager. Also decrement the
Issued WTP Requirement Qty. In addition, decrement the Required Qty from the WTP (Qty available in the WJP). d. Provide recommendations around the material used to satisfy the WJP. 5) Use this WTP as supply to the Order Allocation and continue the Allocation process. The un-used issued WTP-requirement can be calculated by decrementing that part of issued WTP requirement that was used to construct the "completed" qty of the WTP. WTP Recommendation Date Aggregation The problem that we will now be faced with is that when different nodes in the same ship-set or alternatively even different ship-sets consume the same WTP, they might have different BPD's. Hence, we end up providing multiple recommendations on different parts of the same WTP. There are two options, either split the WTP or Aggregate. However, at this point in time, we do-not support WTP aggregations. Essentially only those quantities of the WTP (same WTP) get aggregated where the feasible available and best date is the same (across orders). Advantages: This method accomplishes WTP Requirement Satisfaction, WJP Pull-in Recommendation and WTP Push-out Recommendation (Due to Infeasibility). Example / Use Case for WTP Consider a typical manufacturing environment (NET ex.) where they do final Assembly and Test Operations. Let us consider the Assembly for the Router. • NET procures their Casing and Motherboard from Supplier- 1 • All their PCA cards from Solectron ™ o PCA1 o PCA2 • Power Supply and other Electro-Mechanical Components from Supplier-2
40 Let there be a WTP (Flow schedule) of 4 from the initial demand. The shop floor personnel had taken 4 power supplies to build this. This flow schedule (WIP) was scheduled for today. However, they find that the PCA cards have not been tested and this test would take two days. In addition, they also expect a shipment of casings only tomorrow. SDM WTP Working: In Order to build the demand of 5 routers, the pre-issued WTP of 4 could be used. In addition a new WTP of 1 needs to be issued to satisfy this order. In addition, the operations person should understand when these WJP's are feasible and hence the final order. Since, there is a requirement of PCA cards (5 of each type to be tested, they would take two days). The casing shipment would also come in only after a day. Hence, the feasible date for the WIP would be two days hence. Also, since the final assembly takes a day, the order would be available only three days hence. Results: SDM Mechanism would hence report the following messages. Order Details: Referring to Figure 33, the following are illustrated: Buildable Supply Problem
Supply and STO Functionality. A Stock-Transport-Order (STO) is modeled between two visible sites. In essence, an STO can be thought of as a blanket PO that is issued between an OEM and a CM against which a CM executes. An STO is thus an execution statement to a CM to release material in a set time frame. When a CM released material against this STO, there are two possible states for this material. This could have been received by the OEM and is accounted for in the OEM's inventory pool. In this case, the received quantity in the STO is incremented to account for this inventory. Alternatively, material that has been released by the OEM could be in-transit and not have been received by the OEM. This is modeled as an ASN (Advance Shipping Notice). An STO is a statement of execution to transfer components from one site to another.
An STO has a projected completed date and a quantity. The OEM site might have received some parts of the STO and some parts of the STO would be in the state of being shipped/ Hence, while looking at the STO as a source of Supply, the system needs to accomplish the following things. Use the ASN as a firm source of Supply. Ensure that the remaining STO (or the part of the STO that is used) will be feasible. In other words, we will allocate material at the lower level to fulfill this STO (The total remaining STO is STO qty - Received Qty - ASN qty against this STO). And, allocate additional material to an STO only if used by an actual order or sales forecast
Figure imgf000042_0001
41 1) Allocate in the order of ship set priority 2) Arrange Supply in an order of "Issued Qty against WTP Requirements", ASN's, On-Hand, WIP's and PO's in the earliest available order. (This order should be driven off a system parameter and currently this should be the default order). In addition as in 2.1 continue to allocate non-short supply before short supply across the board. 3) If we allocate STO's, allocate them with Feasible Available Date 4) In order to find the feasible available date, a. The Required Qty is the requirement at that node. b. In Order to compute the Feasible Available Date, i. Treat the STO as a demand source. ii. Allocate to this STO as we would allocate to a ship-set. iii. However, we must first use the ASN before we consider any other sources of supply (same order as above) iv. Obtain the Feasible Available Date for the STO based on the availability of the allocated lower-level supply. v. The Best possible Date is constructed as in every other supply situation with the best possible date at the lower levels c. Decrement the Supply used from the Supply Manager. d. Provide recommendations around the material used to satisfy the STO. 5) Use this STO as supply to the Order Allocation and continue the Allocation process. STO Recommendation Date Aggregation The problem that we will now be faced with is that when different nodes in the same ship-set or alternatively even different ship-sets consume the same STO, they might have different BPD's. Hence, we end up providing multiple recommendations on different parts of the same STO. As we have two options here: Split the WTP or Aggregate. However, at this point in time, we do-not support STO aggregations. Essentially only those quantities of the STO (same WJP) gets aggregated where the feasible available and best date is the same (across all order allocations). BOD Functionality In order to ship an end-assembly from one site, material and sub-assemblies are sourced from different sites. This is achieved through the help of the BOD functionality. Consider an appropriate Supply, in line with the way supply is sourced in the case of Demand Exploder & DOS, E&O, we need to make sure that we don't double count the
42 supply or consider inappropriate supply. In this regard, we should consider the following entries: 1) Entry in BOD (This will determine how the explosion of demand needs to proceed). It should be noted that we should not have BOD's to a non-visible site. 2) Explode Flag (A new Explode Flag needs to be set at a part-site level. This will be used where some parts should not be exploded or supply-demand rationalization does not need to happen.). This can be used for many purposes if explosion is not desired. Often times, OEM's hold Supplier BOM' s. However, they would not prefer to explode and understand allocation at that level. Single Sourcing: Single sourcing environments can be supported to the supply logic by incorporating the following. • Supply Site added as a parameter to each node • Lead times between sites are captured. Multi Sourcing: Multi-sourcing environments have a multitude of ways in which they operate. Some of them are described below. 1) Prioritized Sourcing - This is a case in which the OEM usually sources from one supplier and sources from another supplier in the case of unavailability from the preferred supplier. (We don't support this currently) 2) Order Specific Sourcing - If the customer / order has specific sourcing requirements from a supply source due to regional constraints. However, this problem can be modeled as a single sourcing problem and hence is not an issue. 3) Sourcing Percentages - When the OEM has contractual obligations from multiple suppliers; they might employ this mechanism of sourcing a part of their requirements from each supplier. The demand exploder currently uses sourcing percentages logic to solve a multi-sourcing problem. Since sourcing percentages are applied during a more mid-term supply positioning time horizon, we would need to apply this only at the time where the SDM Module is used as a supply-positioning tool. If the SDM Module is used as an allocation tool, then we take the assumption that supply has already been positioned against a long-term demand in all the sourcing sites, honoring the percentage commitments. Hence, at order allocation time, we will not apply sourcing percentages. These various options need to be supported:
43 I) SDM used as a supply-positioning tool - Honor Sourcing Percentages at all cost and issue supply recommendations, as this is a long-term supply positioning strategy. We are currently not addressing this capability. II) SDM used at a more tactical level as a fulfillment tool. a. Split Sourcing - In component sourcing environments like at AFC that involves multiple sourcing options, all supply is ultimately dropped at the OEM buffer. The supply here is then consumed. Hence, it would suffice to arrange supply from multiple sources in an as available mode and then source the earliest to satisfy orders. In addition, an overriding factor to this is we don't want to issue new supply whenever it can be avoided. b. Complete Sourcing - In a completely drop-ship environment like at Juniper, whole ship-sets needs to be sourced from one supply source. However, given that order fulfillment is still the key problem that the SDM engine is trying to solve here, supply at multiple sources should be arranged in an as-available fashion. However, we should fulfill an order completely from only a single site. In addition, an overriding factor to this is we don't want to issue new supply whenever it can be avoided. Mechanics: The basic logic is that the order of priority of sourcing is 1) Source real components and avoid issuing new supply 2) Source earliest available supply Split Sourcing: The logic here is to source from multiple sites if needed to satisfy a given order. Hence, the method followed will be as follows. 1) Propagate complete demand to all sourcing option sites. 2) Create bundles from all these sites to satisfy the demand. Hence supply will be demand*no of sourcing options. 3) Arrange in two buckets a. Bundles with no shortages b. Short Bundles 4) Choose earliest from the bucket with no shortages. 5) If we run out of supply in the first bucket, then choose earliest from second bucket. 6) Throw away unallocated supply.
44 Note: There is no concept of degree of shortness that we present here. A bundle is short if one part is short or if 100 parts are short. This is because it is impossible to distinguish between shortness especially if they occur at different levels. Ex:
Referring to Figures 34-36, the following steps are illustrated: Step 1: Propagate demand to both sites, Step 2: Source total demand from both sites, Step 3: Arrange Supply in two buckets - Real and short and choose top 50 from that. Complete Sourcing: The logic here is to source from a single to satisfy a given order in the earliest available mode. However, we will consume real supply before we consume later supply. 1) Propagate complete demand to all sourcing option sites. 2) Create bundles from all these sites to satisfy the demand. 3) Arrange in two buckets a. Bundles with no shortages b. Short Bundles 4) Choose earliest from the bucket with no shortages (All chosen bundles should be from a single site) 5) If we run out of supply in the first bucket, then choose earliest from second bucket. (All chosen bundles should be from a single site) 6) Throw away unallocated supply. Note: There is no concept of degree of shortness that we present here. A bundle is short if one part is short or if 100 parts are short. This is because it is impossible to distinguish between shortness especially if they occur at different levels. As an example, Referring to Figures 37-39, the following steps are illustrated: Step 1: Propagate demand to both sites Example.-Demand of 50 is propagated to both sites - Total demand is 50 Step 2: Source total demand from both sites Step 3: Arrange Supply in two buckets - Real and short and choose top 50 from that. (Malce sure that all bundles are from the same si Calendar Support in SDM There are three types of calendars that need to be incorporated into SDM. a) Site Calendar b) Site Shipping Calendar
45 c) Site Receiving Calendar At this point in time, we will only be developing site calendars and site shipping calendars. Site Calendar: The site calendar influences the operations of a company when at that site and will determine the effectiveness of the lead-time. For example, if the lead-time for manufacturing is seven days and the company works only on the weekdays, a manufacturing operation that starts on Monday will only be completed the Tuesday of next week. This will be configurable to affect the lead-times associated with make, buy and transfer. (Manufacturing lead-times, STO lead-times and PO lead-times). As it is site specific, this will apply to the Ηeld-At" site where the make, buy or transfer operation is performed. Site Shipping Calendar: Every site will have a calendar that determines when it can ship material to another site or to the customer. Hence, if a product is manufactured / assembled by a site on Monday and shipments happen only on Wednesdays, SDM should incorporate this and transfer the parts only on Wednesday. Again, this should be for the site that actually ships the product. Scheduler Business Driver for Flux: SDM is an order fulfillment tool that helps the scheduling team assess when Orders can be met given the current supply. It also enables the schedulers to assess the supply that is required in addition to the already positioned supply. SDM runs in two modes. One is a daily / bi-daily process that runs based on a pre-specified set of rules
(Ranking Strategy / SDM Business Rules etc.). The other one is a manually triggered what-if- mode of running. The daily process is triggered simulation that runs using a scheduling tool called Flux. Flux Functionality Description: Flux is the scheduling tool that triggers SDM runs in specified intervals of time. Flux enables the following: 1) Flux enables the running of SDIVI in pre-specified intervals of time. 2) An XML file can be configured to specify the various properties of this triggered XML run. The various configurations supported are a. Trigger Mechanism - The SDM run can be time-triggered or event triggered. Currently, flux is configured for event trigger. SDM runs after every ETL run (The event here is the end of ETL). b. Pre-set Rule based on a 'Saved SDM run' - A saved SDM is referenced to access the various rules based on which the flux triggered simulation needs to run. SDM follows the rules that this saved simulation has. The various pre-specified rules are:
46 i. Ranking Strategy ii. Business Rules - Delay and Shortage Options iii. Demand and Supply Parameter Selections c. Time Selections of Demand and Supply Pages are rolled forward - Every SDM run allows you to specify the dates for which the demand and supply needs to be selected. However, if these dates are picked up from the reference run, the triggered run will not pick up the current demand or supply. Hence, the selection dates are rolled forward. For example, if the sys.date for the reference run was June 1st and the selected dates for the demand are from May 20th to Aug 1st, then the triggered simulation that runs on June 2nd based on the reference simulation will pick up all demand between May 21st and Aug 2nd. d. Time Selection can be overridden - The user can specify that the rolling can be overridden by specifying actual dates in the XML document. In this case, the triggered simulation will always pick the same dates. e. The name for the triggered simulation can be specified in the XML document - The XM document contains the name of the triggered simulation. Every time, a simulation is triggered a time-stamp is attached to this simulation name in order to create a unique simulation. 3) Flux can be scheduled to either run a complete simulation or to extract the demand only based on the rules defined in the XML document and the referenced simulation. a. If the complete simulation is run, then SDM reporting can be used to access the results. b. If only the demand is extracted (similar to the export), then the location of the file can be pre-specified by the user. Use Case 1 - Quarter End Scenario Consider the case where an organization realizes revenue when the customer has received goods. In addition as most companies do, assume an environment where financial reporting on a quarterly basis is the norm. Hence, during quarter end, it becomes necessary for this company to accelerate its revenue for the quarter and not let the revenue slip into the next quarter. This is important to meet their financial needs. Let us also assume an environment like consumer electronics where partial shipments are valid. In order to accomplish this, the company, during this time period would aim to 1) Prioritize their Higher Margin Orders and 2) Ship as much as they can before the quarter end. In this situation, SDM could be set up to run in the following fashion. The user could rank the demand statements in order of higher margin. Choose "Create New Supply" as the
47 Shortage Policy, then Choose "Ship Partial" as the Delay Policy. The user could then act on the recommendations of SDM in-order to satisfy the company objectives. Use Case 2 - Expedite Request from Customer or Supply Shortfall SDM is aimed to work in multiple scenarios. Referring to Figure 40, a flow diagram of some scenarios is illustrated. It could be used as a regular process. Else, it could be used in an as-needed fashion. First, a focus on the as-needed fashion. Assume that the order fulfillment desk receives an expedite request from a very important customer. In order to satisfy that request, it is most certain that other orders that were scheduled at that time would get impacted. SDM could help in this situation by building a what-if simulation that simulates the expedite request. The Order Management Personnel could then assess the impact on
Order Fulfillment given the current state of supply. If acceptable, the expedite request could be met and the expectations with other customers could be reset. Else, the Order Management person / planner could work with the commodity manager and supplier / CM on the supply side by working on the recommendations provided by the SDM module on the supply side. Thereby the user could better the Order Fulfillment Situation and then on a subsequent run of SDM again assess the impact with the recommendations and then reset expectations with a lesser number of customers. Use Case 3 - Regular Recommended Mode In the most normal case, the recommended mode of running is as follows. The company should reflect the rankings of the demand, consistent with overall company objectives. SDM should be run with the following policies. If Shortage - Create New Supply. If Delay - Reconcile Delayed Orders These policies would ensure that the business would maximize their revenue in the long turn. In addition, SDM provides recommendations on both the supply and Demand side. Care should be taken to time the recommended actions in a synchronous fashion. For example, the organization should ensure that customer expectations are not getting reset while supply recommendations are implemented in order that the prior expectations are not reset. For example, SDM could be run in the morning and supply recommendations that come out (Whatever can be accomplished) can be fed into the ERP system. Following this, SDM can be re-run again during the day and this time, the demand side recommendations could be implemented. Hungry Algorithm Introduction The allocation algorithm is an automatic allocation process which assigns end- products, sub-assemblies and components to a sales order by working with bills of material of
48 the products that comprise the sales order. The algorithm utilizes a Supply and Demand Matching Algorithm for calculating schedules according to available supply and current demand, based on orders. The Allocation algorithm takes into account the complexities associated with sales orders - many line items, ship sets, partial shipments, ship model complete flags - and provides an immense amount of allocation detail when it has finished running. A large number of answers about the allocation can be answered by looking at the result of the algorithm. In addition, a variety of "what-if allocation scenarios can be run by a user of the Hungry Allocation algorithm. Definitions BOM Tree: A Bill of Materials tree for a product describes how the product is constructed, as a set of nodes and arcs. The top node is the end product, intermediate nodes represent sub-assemblies, and leaf nodes represent components. Node: A node represents an order, a product, sub-assembly or component. Each node has one parent and one or more children. A top node has no parent, and leaf nodes have no children. Arc: Between any parent and child, there is an arc. Bundling Number: Every arc is labeled by a bundling number. The bundling number represents the number of units of the child that are required to be assembled into the parent. Bundle: The collection of units of a child that can be moved up an arc to a parent.
The number of units is given by the bundling number of the arc. Bundling Condition: This is the condition under which a node can assemble the bundles received from its children and create a bundle of its own. The default bundling condition is: a bundle must contain one bundle from each of the children nodes. Supply: Available supply at any node. This represents inventory, WTP and PO's, or as selected by the user. Supply is stored in a single table in memory. Therefore, repeated nodes in a part look at the same table when they need supply. If supply is allocated to a node, it is correspondingly reduced from the supply table, thus making it unavailable to a second occurrence of the same node, which will look at the same (single) supply table. Allocation: Hungry Allocation stores allocation as a nested list of assemblies, sub- assemblies and components. An allocation list provides (in addition to the quantity allocated) the exact manner in which that allocation has been theoretically assembled. As an example, an allocation at the top node for product P might look like this: 5 + 2(1,2) + 3((2,4), 2(4,7)) ...
49 In other words, the allocation consists of 5 units of P, 2 units of P assembled from its sub- assemblies (which provide 1 and 2 units respectively), and 3 units of P assembled from sub- assemblies which in turn have been assembled from their own components. Algorithm The algorithm works on a top down strategy, starting at the topmost node (product or order) and moving down the BOM tree if and when needed. Node Operations Two recursive operations describe the algorithm: 1. Calculate the move-up number, m_i, for each sibling node: divide (and truncate to integer) the QOH at the node by the bundling number above it. 2. If min(m_i) > 0 push min(m_i) bundles from each sibling to the parent increase supply of parent by min(m_i) (using the default bundling condition) decrease supply of each sibling by min(m_i)*bundling_number_i ascend to parent node and repeat Step 1 else descend to children nodes of the first sibling whose m_i = 0 repeat Step 1 Algorithm Operation Modes The Hungry Allocation can work in two modes: Storage and Hungry:
Shortage Identification Mode 1. Start at the topmost ("order" or "product") node, with m_i = 0 and perform steps 1 and 2 above. 2. Stop when any one of two conditions is satisfied: a: m_i at the the top = DEMAND (full allocation) b: A leaf node has m_i = 0 (short component) Hungry Mode 1. Start at the topmost ("order" or "product") node, with m_i = 0 and perform steps 1 and 2 above. 2. If a leaf node has m_i = 0, add a large number of fictitious units to it, mark those units as fictitious, and continue. 3. Stop when m_i at the top node = DEMAND
50 The allocation can now be read from the allocation list at the topmost node. This allocation is maintained as a nested list of sub-assemblies and components. It shows the exact manner in which units of the product can be assembled. The first mode of operation will stop as soon as a short component is identified, or when allocation is complete. The second mode of operation is more powerful. It will always allocate fully, because all shortages will be made up by fictitious units. In the process, it will be able to identify all short components, their shortage quantities, and provide a great deal of insight into the allocation scenario. In the rest of this document, we assume that the algorithm is run in the Hungry mode. Features of the Hungry Allocation Algorithm are numerous. Instead of trying to calculate total component shortages, the algorithm attempts to carry out a complete allocation, and stumbles upon shortages as they occur. This allows the algorithm to gain a far greater insight into the nature of the shortage (which components experience a shortage first? How many units could we have assembled (and shipped) before the shortage made itself felt?) . It moves in chunks toward the final goal of complete allocation. In the worst case, it reduces to "allocate one at a time". This worst case, however, will rarely occur unless the BOM is absurdly complex, and supply is distributed in an absurdly complex way at all levels of the BOM. In all cases (even for complex BOM's), the algorithm will speed up after the supply at intermediate levels has been exhausted. In that sense, the algorithm can be very efficient, and its worst case efficiency can be calculated. The general policy of the algorithm is to go down the BOM tree only when absolutely necessary, and to never go down more than required. So, the supply at any level will typically not consist of too many nested lists (except at the top level). It can handle partial shipments: the final allocation at the product node contains the breakup of exactly how many units have been assembled in what manner. This can easily tell us how many of the short components (if any) are needed to ship a partial quantity of the order. For the same reason, this algorithm can also handle order splits very efficiently. It can handle ship sets: a ship set can be enforced by simply putting the appropriate bundling numbers on the arcs from the order node to the products node. If there are no ship sets, an order node is not needed. There can be one tree for every product, and each tree is independent, except in reading from the same supply table. It will not allocate unnecessary components to an order: for instance, some orders require products, components and sub-assemblies in bundles, (e.g. some sub-assemblies are
51 always used in multiples of two, so there is no point assigning three sub-assemblies to an order). Similarly, if a product requires 6 units of a sub-assembly in a bundle, there is no point assigning seven sub-assemblies to it. The algorithm will extend to many more complex allocations. By playing with the bundling condition and bundling numbers, we may be able to account for many other complexities of order allocation. It will identify all short components in order. The components which are most crucial will be identified first. Note that demand is ignored while running the algorithm, which is like a hungry assembly line. As soon as components which make a sub-assembly are available, the sub-assembly is made and pushed up the BOM. And as soon as all sub-assemblies are available, a product is made and pushed out. This keeps happening until demand is satisfied at the highest level. This also means that the algorithm might overshoot the actual demand (because it assembles products in chunks, not unit by unit). To account for this, a slight reversal may have to be done if the total supply at the topmost node exceeds demand. This is not an issue if there is a shortage (because then the algorithm cannot possibly overshoot demand), but is an issue when the entire allocation is possible. Allocation at any level will have to be kept as a nested allocation list, which distinguishes a sub-assembly from a theoretical sub-assembly made up of components. The allocation list at the product node describes the complete allocation when the algorithm stops. Before moving on to the next product, the supply tables in memory will have to be adjusted to subtract the allocation already done in the current product. This can be done by looking at the nested allocation list at the product node. This also means that intermediate bundles which have been pushed up in the current BOM will be destroyed, because they exist only as theoretical assemblies. If a component goes into one and only one sub-assembly, then the "aggregated BOM" which is generated by the Hungry Allocator can provide information to speed up future allocations, because it has already assembled (theoretically) those components and made them available as sub-assemblies. However, if that component is also used in other sub- assemblies, then this aggregated BOM will provide incorrect information and should not be used. The Hungry Allocation algorithm is very useful in running what-if scenarios, because an immense amount of information is present (and organized) once the algorithm has run and carried out its allocation. We can answer questions such as how many units can we allocate
52 without experience a component CI shortage? How many can we allocate with 5 Cl's and without experiencing a C2 shortage? And so on. SDM example Consider the BOM/BOD combination P is the complete product. A is a Sub assembly B is a sub-assembly X is a component part Y is a component part STO is a Stock Transfer Order
For this first example: P = A + 2B A = leaf B (site 1) = B (site 2) or B (site 3) B (site 2) = X + Y B (site 3) = X + 2Y Demand P = 50 Supply
Figure imgf000054_0001
53
Figure imgf000055_0001
Note for this example: 1. SB1 and SB2 are existing STO's placed by sitel on site2 2. SB3 and SB4 are existing STO's placed by sitel on site3 3. There is no issued qty for WP3 4. When the supply tied to an ASN is received, the received qty of the corresponding STO is increased accordingly, and the ASN vanishes from the database. So it is safe to assume that an ASN will deliver all its released_qty on its scheduled receipt date. (An ASN that is received will probably go into the receipts_ft, but that is not of interest). 5. The qty to be delivered by a WTP is (start - complete), where complete_qty has been adjusted with on-hand. Similarly, the qty to be delivered by an STO is (original - received) where received has been adjusted with with On-Hand (Lou seems to use Open Quantity for original - received) 6. At the supplying site, the ASN issued against an STO is adjusted with On-Hand at that supplying site. In other words, On-Hand at the supplying site is fully available for use to meet other existing STO's or to make new STO's 7. Issued Qty, we always means "unused issued" in wip requirements. We must use the complete qty of the WTP to calculate the unused issued qty for its corresponding wip requirement. These is no concept of unused issued for an ASN, because an ASN is delivered on one date. It is either fully "non received" or fully received. Solution 1. D(P) = 50 2. Issued(P) = 0. QOH(P) = 5. STO(P) = PO(P) = 0. Allocate 5(P) 3. D(P) = 50 4. Issued(P) = QOH(P) = STO(P) = PO(P) = 0. Allocated(P) = 5. Descend P. 5. D(A) = 45, D(B) = 90 6. Issued(A,WPl) = 2. Issued(A, WP2) = 4. QOH(A) = 2. PO(A) = 2. Committed(WPl). M(A) = 6
54 7. Issued(B,WPl) = 1. Issued(B,WP2) = 4. QOH(B) = 5. Committed to WP1. M(B) = 3 8. Push up bundle(A) and bundle(B). Allocated(WPl) = 1. Complete? NO 9. Issued(A, WP1) = 1. Issued(A, WP2) = 4. QOH(A) = 2. PO(A) = 2. Committed to WP1. M(A) = 5 10. Issued(B, WP1) = 0. Issued(A, WP2) = 4. QOH(B) = 4. Committed to WP1. M(B) = 2 11. Push up bundle(A) and bundle(B). Allocated(WPl) = 2. Complete? YES This ends the curcent pulling operation. Now the pulling (parent) node must compare its move_up number with its siblings, in an attempt to move further up the tree. In one embodiment, pulling operation (at a BOM node) terminates when the pulling (parent) node has pulled as many bundles as the minimum move_up number of its children. In another embodiment, a pulling operation (at a BOM node) terminates in either of two situations: A. The pulling (parent) node has pulled as many bundles as the minimum move_up number of its children. B. The WTP (or STO) being constructed is complete, (as in Step 11). In other words, "one pull" breaks up into as many pulls as there are pre-defined WIP's or STO's. After the end of each pull, the parent node attempts to move up the tree.
Moving up the tree: 12. D(P) = 50 13. Issued(P) = QOH(P) = STO(P) = PO(P) = 0. Allocated(P) = (5 + 2 WP1). Descend P 14. D(A) = 43, D(B) = 86 15. Issued(A, WP1) = 0. Issued(A, WP2) = 4. QOH(A) = 2. PO(A) = 2. Committed to WP2. M(A) =8 16. Issued(B, WP1) =0. Issued(B, WP2) = 4. QOH(B) = 2. Committed to WP2. M(B) = 3 17. Push up bundle(A) and bundle(B). Allocated(WP2) = 1. Complete? NO 18. Issued(A, WP1) =0. Issued(A, WP2) = 3. QOH(A) = 2. PO(A) = 2. Committed to WP2. M(A) =7
55 19. Issued(B, WP1) =0. Issued(B, WP2) = 2. QOH(B) = 2. Committed to WP2. M(B) = 2 20. Push up bundle(A) and bundle(B). Allocated( P2) = 2. Complete? NO 21. Issued(A, WP1) =0. Issued(A, WP2) = 2. QOH(A) = 2. PO(A) = 2. Committed to WP2. M(A) =6 22. Issued(B, WP1) =0. Issued(B, WP2) = 0. QOH(B) = 2. Committed to WP2. M(B) = 1 23. Push up bundle(A) and bundle(B). Allocated(WP2) = 3. Complete? NO This ends the pulling operation, because the minimum move up number of B was 3, and three bundles have been pulled up. Keep in mind that WP2 has not been fully constructed, so we are still committed to it. Let us now try to move up the tree: 24. D(P) = 50 25. Issued(P) = QOH(P) = STO(P) = PO(P) = 0. Allocated(P) = (5 + 2 WP1 + 3 WP2). Descend P 26. D(A) = 40, D(B) = 80 27. Issued(A, WP1) = 0. Issued(A, WP2) = 1 . QOH(A) = 2. PO(A) = 2. Committed to WP2. M(A) = 5 28. Issued(B, WP1) = 0. Issued(B, WP2) = 0. QOH(B) = 0. Committed to WP2. M(B) = 0 As in 2.2, when a child reports a move_up number of zero we must descend the tree at that child. In this case, the child happens to be a BOD node. So we carry out two mini-allocations (because the BOD node has two potential suppliers). Remember that we are still committed to WP2. Source 80 units of B. Construct 80 units in site2 and site3. Assuming an existing STO (at sitel) has a pre-assigned supply site, there is no need to try and allocate to it in any other supply site except the one assigned to it. These are the potential allocations we get at site 1 from site2 and site3 (details in the next section): From Site 2 Allocated(B) = 3 SB1 + 1 SB1 + 3 SB2 + 9 NEW_ST01 + 1 NEW_STO2 + 2
NEW_STO3 + 2 NEW_STO4 + 59 NEW_STO5 Committed to WP2. From Site 3 Allocated(B) = 4 SB3 + 3 SB4 + 71 NEW_STO6 + 2 NEW_STO7. Committed to WP2
56 Compare the bundles of B from site2 and site3 and select 80 bundles from the better site or the best mix, depending on the split_sourcing__flag, bundle dates, and whether the bundles contain short components. Let us assume that the split_souring_flag is Y, and that we take a mix of bundles which looks like this: At Site 1 Sourced(B) = 3 SBl + 1 SBl + 3 SB2 + 9 NEW_ST01 + 4 SB3 + 3 SB4 + 57 NEW_STO6 Note that the entire SBl has been taken, but SBl was actually constructed in two parts. It is useful to ensure that an entire STO is taken. In one embodiment, when the bundles are arranged in time, parts may be taken of different STO's. This is true for WIP's also. Continuing: 29. Issued(A, WP1) = 0. Issued(A, WP2) = 1 . QOH(A) = 2. PO(A) = 2. Committed to WP2. M(A) = 5 30. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2. Sourced(B) = 3 SBl + 1 SBl + 3 SB2 + 9 NEW_STOl + 4 SB3 + 3 SB4 + 57 NEW_STO6. M(B) = 40 31. Push up 4 bundles of A and B, one at a time. Allocated(WP2) = 7. Complete? YES 32. D(P) = 50 33. Issued(P) = QOH(P) = STO(P) = PO(P) = 0. Allocated(P) = (5 + 2 WP1 + 3 WP2
+ 4 WP2). Descend P 34. D(A) = 36, D(B) = 72 35. Issued(A, WP1) = Issued(A, WP2) = Issued(A, WP3) = QOH(A) = 0. PO(A) = 1. Committed to WP3. M(A) = 1 36. Issued(B, WP1) = Issued(B, WP2) = Issued(B, WP3) = QOH(B) = ASN(B) = 0.
Committed to WP3. Sourced(B) = 8 NEW_STOl + 4 SB3 + 3 SB4 + 57 NEW_STO6. M(B) = 36 37. Push up 1 bundle of A and B. Allocated(WP3) = 1. Complete? NO 38. D(P) = 50 39. Issued(P) = QOH(P) = STO(P) = PO(P) = 0. Allocated(P) = (5 + 2 WP1 + 3 WP2
+ 4 WP2 + 1 WP3). Descend P 40. D(A) = 35, D(B) = 70 41. Issued(A, WP1) = IssuedfA, WP2) = Issued(A, WP3) = QOH(A) = PO(A) = 0. Committed to WP3. M(A) = 0.
57 42. CREATE NEW_PO3(A) = 35. M(A) = 35 43. Issued(B, WP1) = Issued(B, WP2) = Issued(B, WP3) = QOEC(B) = 0. Committed to WP3. Sourced(B) = 6 NEW_STOl + 4 SB3 + 3 SB4 + 57 NEW_STO6. M(B) = 35 44. Push up 4 bundles of A and B, one at a time. Allocated(WP3) = 5. Complete? YES 45. D(P) = 50 46. Issued(P) = QOH(P) = STO(P) = PO(P) = 0. AUocated(P) = C5 + 2 WP1 + 3 WP2 + 4 WP2 + 1 WP3 + 4 WP3). Descend P 47. D(A) = 31, D(B) = 62 48. Issued(A, WP1) = Issued(A, WP2) = Issued(A, WP3) = QOH(A) = PO(A) = 0.
Committed to no WTP. M(A) = 31 49. Issued(B, WP1) = Issued(B, WP2) = Issued(B, WP3) = QOH(B) = 0. Committed to no WTP. Sourced(B) = 2 SB3 + 3 SB4 + 57 NEW_STO6. M(B) = 31 50. Push up 31 bundles of A and B, one at a time. CREATE NEW_WTP2 51. D(P) = 50 52. Issued(P) = QOH(P) = STO(P) = PO(P) = 0. Allocated(P) = (5 + 2 WP1 + 3 WP2 + 4 WP2 + 1 WP3 + 4 WP3 + 31 NEW_WTP2) 53. END Allocation at Site 2 1. D(B, sitel) = 80. 2. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2. Source B 3. D(B, site2) = 80 4. Issued(B, SBl) = 1. Issued(B, SB2) = 2. QOH(B) = 2. PO(B) = 0. Committed to SB1. M(B) = 3. 5. Push up 3 bundles of B, one at a time. Allocated(SBl) = 3. Complete? NO If (B, sitel) was a BOM node, we would have tried to move up the tree with the move_up number we have now. But this is a BOD node, which means we must complete the mini- allocation of 80 units before moving up. So, continue the pulling operation: 6. D(B, sitel) = 80. 7. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2.
Allocated(B) = 3 SBl. Source B 8. D(B, site2) = 77 9. Issued(B, SBl) = 0. Issued(B, SB2) = 2. QOH(B) = 0. Committed to SBl. M(B) = 0. Descend B
58 10. D(X) = 77. D(Y) = 77 11. Issued(X, WB 1)=5. Issued(X, WB2) = 2. QOH(X) = 0. PO(X) = 7. Committed to WB1. M(X) = 12 12. Issued (Y, WB 1) = 4. Issued(Y, WB2) = 3. QOH(Y) = 2. PO(Y) = 5. M(Y)= 11 13. Push up 11 bundles of X and Y (one at a time). Allocated(7WB 1) = 11. Complete?
NO 14. Push up 1 bundle of B. Allocated(SB 1) = 4. Complete? YES
In this case, the pulling operation (from sitel) is interrupted after 1 pull because SBl is complete, although the move_up number was 11. Let us try to move up the tree in sitel. But (B, sitel) is a BOD node, so we must go back down until the mini-allocation is complete. 15. D(B, sitel) = 80. 16. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2. Allocated(B) = 3 SBl + 1 SBl. Source B 17. D(B, site2) = 76 18. Issued(B, SBl) = 0. Issued(B, SB2) = 2. QOH(B) = 0. Committed to SB2. Allocated(WBl) = 11 - 1. M(B) = 12 19. Push up 3 bundles of B, one at a time. Allocated(SB2) = 3. Complete? YES 20. D(B, sitel) = 80 21. IssuedfB, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2.
Allocated(B) = 3 SBl + 1 SBl + 3 SB2. Source B 22. D(B, site2) = 73 23. Issued(B, SB 1) = Issued(B, SB2) = QOH(B) = 0. Committed to no STO. Allocated(WBl) = 11 - 2. M(B) = 9 24. Push up 9 bundles of B , one at a time. CREATE NEW_STO 1. Let us assume the dates of all 9 bundles are the same, allowing us to create one NEW_STOl for them. Otherwise we would have created as many new sto's as we had (part, date) combinations. 25. D(B, sitel) = 80. 26. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2.
Allocated(B) = 3 SBl + 1 SBl + 3 SB2 + 9 NEW_STOl. Source B 27. D(B, site2) = 64 28. Issued(B, SB 1) = Issued(B, SB2) = QOH(B) = 0. Committed to no STO. Allocated(WBl) = 11 - 11. M(B) = 0. Descend B
59 29. D(X) = 64. D(Y) = 64 30. Issued(X,WBl) = 0. Issued(X, WB2) = 2. QOH(X)=0. PO(X)=l. Committed to WB1. M(X) = 1 31. Issued (Y, WB1) = 0. Issued(Y, WB2) = 3. QOH(Y) = PO(Y) = 0. Committed to WB1. M(Y)= 0 32. CREATE NEW_PO 1 for Y = 64. M(Y) = 64
This PO may be for a larger amount than we need, because some Y may be sitting around in issued_qty, but we have no way of knowing that. 33. Push up 1 bundle of X and Y(X). Allocated(WB 1) = 12. Complete? YES 34. Push up 1 bundle of B . CREATE NEW_STO2 35. D(B, sitel) = 80. 36. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2. Allocated(B) = 3 SBl + 1 SBl + 3 SB2 + 9 NEW_STOl + 1 NEW_STO2. Source B 37. D(B, site2) = 63 38. Issued(B, SB 1) = Issued(B, SB2) = QOH(B) = 0. Committed to no STO.
Allocated(B) = 0. M(B) = 0. Descend B 39. D(X) = 63. D(Y) = 63 40. Issued(X,WB 1) = 0. Issued(X, WB2) = 2. QOH(X) = 0. PO(X) = 0. Committed to WB2. M(X) = 2 41. Issued (Y, WB1) = 0. Issued(Y, WB2) = 3. QOH(Y) = PO(Y) = 0. Allocated(Y)
= 63 NEW_POl. Committed to WB2. M(Y) = 66 42. Push up 2 bundles of X and Y, one at a time. Allocated(WB2) = 2. Complete? NO 43. Push up 2 bundles of B, one at a time. CREATE NEW_STO3 44. D(B, sitel) = 80. 45. Issued(B, WPl) = Issued(B, WP2) = QOH(B)) = 0. Committed to WP2.
Allocated(B) = 3 SB1 + 1 SBl + 3 SB2 + 9 NEW_STOl + 1 NEW_STO2 + 2 NEW_STO>3. Source B 46. D(B, site2) = 61 47. Issued(B, SBl) = Issued(B, SB2) = QOH(B) = 0. Committed to no STO. Allocated(B) = 0. M(B) = 0. Descend B 48. D(X) = 61. D(Y) = 61 49. Issued(X,WB 1) = Issued(X, WB2) = QOH(X) = PO(X) = 0. Committed to ΛVB2. M(X) = 0
60 50. Issued (Y, WB1) = 0. Issued(Y, WB2) = 1. QOH(Y) = PO(Y) = 0. Allocated(Y) = 63 NEW_POl. Committed to WB2. M(Y) = 64 51. CREATE NEW_PO2 for X = 61. M(X) = 61 52. Push up 2 bundles, one at a time. Allocated(WB2) = 4. Complete? YES 53. Push up 2 bundles of B, one at a time. CREATE NEW_STO4 54. D(B, sitel) = 80. 55. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2. Allocated(B) = 3 SB1 + 1 SBl + 3 SB2 + 9 NEW_STOl + 1 NEW_STO2 + 2 NEW_STO3 + 2 NEW_STO4. Source B 56. D(B, site2) = 59 57. Issued(B, SBl) = Issued(B, SB2) = QOH(B) = 0. Committed to no STO. Allocated(B) = 0. M(B) = 0. Descend B 58. Issued(X,WB 1) = Issued(X, WB2) = QOH(X) = PO(X) = 0. Allocated(X) = 59 NEW_PO2. Committed to no WTP. M(X) = 59 59. Issued (Y, WB 1) = Issued(Y, WB2) = QOH(Y) = PO(Y) = 0. Allocated(Y) = 62
NEWJPO1. Committed to WB2. M(Y) = 62 60. Push up 59 bundles of X and Y, one at a time. CREATE NEW_WTP1 Again, it is assumed that all (part, date) combinations are equal in this NEW_WIP1, giving one WTP. Otherwise there will be as many new WPP's as (part,date) combinations. 61. Push up 59 bundles of B, one at a time. CREATE NEW_STO5 62. D(B, sitel) = 80 63. Issued(B, WP1) = Issued(B, WP2) = QOH(B) = 0. Committed to WP2. Allocated(B) = 3 SBl + 1 SBl + 3 SB2 + 9 NEW_STOl + 1 NEW_STO2 + 2 NEW_STO3 + 2 NEW_STO4 + 59 NEW_STO5 64. This completes the mini-allocation from site2. Go to site3 and carry out a similar allocation. Allocation at Site 3 1. D(B, sitel) = 80 2. Issued(B) = QOH(B) = WTP(B) = STO(B) = PO(B) = 0. Committed to WP2. Source B 3. D(B, site3) = 80 4. IssuedCB, SB3) = 2. Issued(B, SB4) = 0. QOH(B) = 76. Committed to SB3. M(B) = 78 5. Push up 4 bundles of B, one at a time. Allocated(SB3) = 4. Complete? YES
61 6. D(B, sitel) = 80 7. Issued(B) = QOH(B) = WTP(B) = STO(B) = PO(B) = 0. Allocated(B) = 4 SB3. Committed to WP2. Source B 8. D(B, site3) = 76 9. Issued(B, SB3) = Issued(B, SB4) = 0. QOH(B) = 74. Committed to SB4. M(B) =
76 10. Push up 3 bundles of B, one at a time. Allocated(SB4) = 3. Complete? YES 11. D(B, sitel) = 80 12. Issued(B) = QOH(B) = WTP(B) = STO(B) = PO(B) = 0. Allocated(B) = 4 SB3 + 3 SB4. Committed to WP2. Source B 13. D(B, site3) = 73 14. Issued(B, SB3) = Issued(B, SB4) = 0. QOH(B) = 71. Committed to no STO. M(B) = 71 15. Push up 71 bundles, one at a time. CREATE NEW_STO6 One new STO may be made, or as many as needed. 16. D(B, sitel) = 80 17. Issued(B) = QOH(B) = WTP(B) = STO(B) = PO(B) = 0. Allocated(B) = 4 SB3 + 3 SB4 + 71 NEW_STO6. Committed to WP2. Source B 18. D(B, site3) = 2 19. Issued(B, SB3) = Issued(B, SB4) = QOH(B) = 0. Committed to no STO. M(B) =
0. Descend B 20. D(X) = 2. D(Y) = 4 21. Issued(X, WB3) = 5, IssuedfX, WB4) = 5, QOH(X)=10. PO(X) = 0. Committed to WB3. M(X) = 15 22. Issued(Y, WB3) =5, Issued(Y, WB4) = 5, QOH(Y) = 5. PO(Y) = 15. Committed to WB3. M(Y)= 12 23. Push up 2 bundles of X and Y (one at a time). Allocated(WB3) = 2. Complete? NO Note that some issued_qty of X and Y to WB3 will be wasted. Also note that we build only a part of WB3 because we don't need all of it. 24. Push up 2 bundles of B, one at a time. CREATE NEW_STO7 25. D(B, sitel) = 80 26. Issued(B) = QOH(B) = WTP(B) = STO(B) = PO(B) = 0. Allocated(B) = 4 SB3 + 3 SB4 + 71 NEW_STO6 + 2 NEW_STO7. Committed to WP2
62 27. This completes the mini-allocation from site3. Compare the bundles of both sites. The Supply Demand Match Algorithm The invention utilizes a Supply Demand Match Algorithm, where the discussion below describes one such embodiment of an algorithm. This algorithm allocates supply to demand using a propreitary algorithm. 1.1 Nodes Let P be a node in the BOM/BOD tree Let N be the set of sibling nodes which are children of P, n\, ι%ι, ..., n# 1.2 Demands Let d\(ni), d2(n,), ... , do(nj) be prioritized demands at node n,-. A prioritization scheme for demand is [demand type, required date]. Demand types can further by prioritized as: Demand associated with WTP's(STO's), unassigned demand. A node can have a BOM parent or a BOD parent, but never both. Therefore the demand at a node can be associated with WIP's or STO's allocated to its parent, but never both. D ε [number of WTP's(STO's) allocated to node P, number of WTP's(STO's) allocated to node P + 1] 1.3 Supply Records A supply record is a collection of identical (or indistinguishable) units. The types of supply records supported by SDM are On-hand, Issued Qty, ASΝ, PO,
WTP, STO, New PO, New WTP and New STO. Let si [dy(ni)], S2[dy(nt) , ..., ss . [dy(nϊ)] be supply records in the supply manager that are eligible to meet demand dy at node π,-. The total number of supply records allocated to node nι and eligible to meet demand dy is Syi. Some supply records are eligible to meet more than one demand at node ni, therefore Syi must be determined one (prioritized) demand at a time, not for all demands together. A prioritization scheme for supply records is [supply type, available date]. Supply types can further be prioritized as: Issued Qty(ASN), On-hand, PO, Allocated WTP(STO), New WTP(STO) Because a node can have either a BOM or BOD parent, Issued Qty and ASN's cannot occur together at the node. Similarly, because a node can either be BOM or BOD, WIP's and
63 STO's cannot occur together at the node. If these incompatible supply types do occur, the supply manager will ignore the supply type that is inappropriate for the node type. 1.4 Supply Bundles Let Q(P, Jit) be the bundling number of node π,-, defined as the number of units of child tit that are required to make one unit of parent P. A supply bundle is a supply measure (consisting of fractional, single or multiple supply records) which contains exactly one bundling number of units. Let bι[dy(ni)], b2[dy(ni)], ..., bβ , [dy(nϊ)] be supply bundles in the supply manager that are eligible to meet demand dy at node nι. The total number of supply bundles (constructed from allocated supply records) at node Hi and eligible to meet demand dy is By/ Some supply bundles are eligible to meet more than one demand at node n,. Therefore Byi must be determined one (prioritized) demand at a time, not for all demands together. 1.5 Move Up Numbers A move up number is a collection of one or more supply bundles at node iii that are eligible to meet demand dy. When a move up number is greater than 1, it refers to identical supply bundles. Let ni\ [dy(ni)] , m2[<iy(«,)] , ... , MM [(dy(nϊ)] , be move up numbers for node iii against demand dy(nl). The total number of move up numbers at node ni that are eligible to meet demand dy
Because supply bundles may be eligible to meet more than one demand at nι, Myι must be determined for one (prioritized) demand at a time, not for all demands together. Supply Demand Match The algorithm will be described as a set of operations at the children of nodes. A node is a junction in the BOM tree of an assembly. Allocation of Supply Records, demand dy at node «/ At node nι, the supply manager determines eligible supply records, Sj[dy(ni)], for demand dy, by matching (part, sites) of the demand with those of the supply. Allocated supply records for demand dy at node ii; are: Sj[dy(ni)] 6 (sι[dy(n , ..., sS yι-\ [dy(ni)]), and fø - ∑^i *-*(««)]) units of sS yι [dy(n ]
where Syi is the smallest integer such that Sy_, sj[dy(nι)] >= dy
64 In the above formula, the last supply record is being split by the supply manager, because the total supply allocation at a node must not exceed demand. Calculation of Move Up numbers, demand dy at node nt A move up number is a collection of supply bundles, calculated from allocated supply records. For demand dy at node n let the first available supply record be Sj[dy(n,)], where a total of Syi supply records have been allocated. c, = l until,/ > Syi do if Y* sx[dy(m)] < Q(P,nl) mc [dy (nl)] = 0 j = syι +ι e\se if sJ [dy (nl )] >= Q(P,nl )
Figure imgf000066_0001
Sj [dy (n, )] = S] [dy (n, )] - Q(P, n, )m<. [dy (n, )] if Sj[dy (nι )] = 0, j = j + l else , [dy (n, )] = ∑^ sx [dy (π, )] + (Q(P, n, ) - ∑^ sx [dy (π, )] units of sk [dy (π, )] where k <= S is the smallest integer such that ^ = sx[dy (n \ >= Q(P,nl )
Figure imgf000066_0002
Sj [dy (n, )] = sJ+1 [dy (n, )] = ... = sk [dy («, )] = 0 sk [dy (rc, )] = sk [dy (Λl )] - (β(P, II, ) - ∑^ sx [dy (II, )]) if ^ [ y (7i, )] = 0, j = k + 1 , else/ = k
Each demand dy at node nt has its own list of eligible supply ^[^(/i,)], which is to be used when calculating move up numbers. These lists may have significant overlap across demands, and will be used up by each demand in order of demand priority.
65 Push Up Operation for Demand dy(ni) Ci = 1 for z = 1...N until ci > Myi for any i, i = 1...N push up min . mq [dy (nt )]) for i = 1.. N mCι [dy (7Ϊ, )] = mCι [dy (n, )] - min . mCι [dy (n,. )]) , i = 1...N if mc [dy (7z, )] = 0 for any i = l...N Ci = ct + 1 end Supply Demand Match Algorithm At node m: Case: nι is a ship set BOM node For demand d (ni) do Allocate supply records to node nt (section 0) d\ - d\ - allocated supply if d\ = 0 stop, else descend m Case: nt is a general BOM node For demands dy(ni), y = 1..D do Allocate supply records to nodes n,-, = 1...N (section 0) Calculate niι[dy(m)], m2[dy(ni)], ..., mM yj [(dy(m)], i = 1...N, (section 0) if min; 7rcλ-[ y(7i;)]) > 0 for any x perform push up operation for demand dy(ni), i = l...N, (section 0) end if push up was successful for any demand dy, y = 1...D ascend to node P and repeat process else descend: if any node nι has mx[dy(ni)] = 0 for all dy, y = 1...D and any x descend n,- else descend any node Once ship sets have been ordered by rank, it allocates supply to them optimally (as defined in the next point). For a given ship set, the algorithm guarantees that it will assemble the largest number of possible bundles in the smallest amount of time, given the current
66 supply. This can be infened from the fact that the algorithm is a breadth-first search: it will not descend any node of the tree until the sibling nodes have assembled at least one bundle each. The algorithm is highly scalable, both with increasing shiptsets and increasing line quantities. The invention has been described in embodiments of a supply and demand matching algorithm for use in a supply chain management system. The invention, however, has many facets, and its scope is broader than the embodiments described, and are defined by the appended claims, whether filed with the application or subsequent to it, and their equivalents.
67

Claims

Claims: 1. A system configured to manage supply chain information according to detailed supply criteria over a broad time line, comprising: a prioritization module configured to prioritize customer product orders according to a supply and demand matching algorithm for calculating predetermined customer criteria and business policy; wherein the algorithm accounts for predetermined relative priorities based on historical customer information including past, current and projected customer product demand; and an assembly planning module configured to establish a unit assembly schedule according to scheduled availability of sub-units.
2. A system according to Claim 1, further comprising a scenario module configured to generate a unit delivery scenario according to customer priority as determined by the prioritization module and an assembly schedule as determined by the assembly planning module, wherein the scenario module is configured to define a unit delivery scenario that provides a delivery schedule for partial shipments of available units at scheduled times based on scheduled availability of sub-units.
3. A system according to Claim 2, wherein the scenario module is configured to establish shipping schedules to ship units as each unit is completed.
4. A system according to Claim 2, wherein the scenario module is configured to manufacturer constraints and lead times of sub-units.
5. A system according to Claim 2, wherein the scenario module is configured to establish shipping schedules to ship full orders of units as orders are completed.
6. A system according to Claim 1, wherein units are finished products and sub- units are components of the finished product, wherein the scenario module is configured to establish shipping schedules to ship finished products as each finished product is completed.
7. A system according to Claim 1, wherein the units are finished products composed of sub-units that include sub-components such as components, sub-assemblies and sub-components, wherein the scenario module is configured to establish shipping schedules to ship finished products as each finished product is completed. 8. A system according to Claim 1, wherein the scenario module is configured to combine customer sales order forecasts with historical sales order data to determine future demands of a customer, wherein the scenario module is further configured to consider customer data in defining a unit delivery schedule.
68
9. A system configured to manage shortages and delays in a supply chain according to supply criteria over a time line, comprising: a prioritization module configured to prioritize customer unit orders according to a supply and demand matching algorithm for calculating supply and scheduling criteria, wherein the algorithm accounts for predetermined relative priorities based on historical customer information including past, cunent and projected customer product demand; an assembly planning module configured to establish a unit assembly schedule according to scheduled availability of sub-units; and a scenario module configured to generate a unit delivery scenario according to customer unit order priority as determined by the prioritization module and by an assembly schedule as determined by the assembly planning module, wherein the scenario module is configured to define a unit delivery scenario that provides a delivery schedule for partial shipments of available units at scheduled times based on scheduled availability of sub-units.
10. A system according to Claim 9, further comprising an intake module configured to receive criterion from a user.
11. A system according to Claim 9, further comprising an intake module configured to receive criterion selected by a user from a predetermined list.
12. A system according to Claim 9, further comprising an intake module configured to receive criterion selected by a user from a predetermined list that includes a scheduled ship date.
13. A system according to Claim 9, further comprising an intake module configured to receive criterion selected by a user from a predetermined list that includes and requires a scheduled ship date.
14. A system according to Claim 9, further comprising an intake module configured to receive criterion selected by a user from a predetermined list, wherein the intake module requires at least one criteria.
15. A system according to Claim 1, wherein unit pertain to finished products and sub-units pertain to component parts.
69
PCT/US2004/042311 2003-12-19 2004-12-15 System and method for supply chain management to allow intelligent shipment scheduling that accounts for shortages and delays WO2005062771A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US53140103P 2003-12-19 2003-12-19
US60/531,401 2003-12-19

Publications (2)

Publication Number Publication Date
WO2005062771A2 true WO2005062771A2 (en) 2005-07-14
WO2005062771A3 WO2005062771A3 (en) 2005-09-29

Family

ID=34738647

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/042311 WO2005062771A2 (en) 2003-12-19 2004-12-15 System and method for supply chain management to allow intelligent shipment scheduling that accounts for shortages and delays

Country Status (1)

Country Link
WO (1) WO2005062771A2 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8626327B2 (en) 2010-11-05 2014-01-07 The Coca-Cola Company System for optimizing drink blends
US8639374B2 (en) 2010-11-05 2014-01-28 The Coca-Cola Company Method, apparatus and system for regulating a product attribute profile
US11151496B2 (en) 2018-02-19 2021-10-19 Target Brands, Inc. Parallel lead time determinations in supply chain architecture
CN115660389A (en) * 2022-12-27 2023-01-31 惠州市金百泽电路科技有限公司 Automatic processing method and system for PCB project order arrangement

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5785329A (en) * 1997-07-28 1998-07-28 Stanley; Douglas G. Cart for draining oil and other liquids from a vehicle
US6151582A (en) * 1995-10-26 2000-11-21 Philips Electronics North America Corp. Decision support system for the management of an agile supply chain
US20020015663A1 (en) * 1989-09-21 2002-02-07 Andrew S. Goldstein Oral collection device and kit
US20020138124A1 (en) * 2001-02-20 2002-09-26 Helfer Jeffrey L. Electromagnetic interference immune tissue invasive system
US20020188499A1 (en) * 2000-10-27 2002-12-12 Manugistics, Inc. System and method for ensuring order fulfillment
US20030149631A1 (en) * 2001-12-27 2003-08-07 Manugistics, Inc. System and method for order planning with attribute based planning
US20030177050A1 (en) * 2001-12-27 2003-09-18 Manugistics, Inc. System and method for order group planning with attribute based planning
US20030200130A1 (en) * 2002-02-06 2003-10-23 Kall Jonathan J. Suite of configurable supply chain infrastructure modules for deploying collaborative e-manufacturing solutions

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020015663A1 (en) * 1989-09-21 2002-02-07 Andrew S. Goldstein Oral collection device and kit
US6151582A (en) * 1995-10-26 2000-11-21 Philips Electronics North America Corp. Decision support system for the management of an agile supply chain
US5785329A (en) * 1997-07-28 1998-07-28 Stanley; Douglas G. Cart for draining oil and other liquids from a vehicle
US20020188499A1 (en) * 2000-10-27 2002-12-12 Manugistics, Inc. System and method for ensuring order fulfillment
US20020138124A1 (en) * 2001-02-20 2002-09-26 Helfer Jeffrey L. Electromagnetic interference immune tissue invasive system
US20030149631A1 (en) * 2001-12-27 2003-08-07 Manugistics, Inc. System and method for order planning with attribute based planning
US20030177050A1 (en) * 2001-12-27 2003-09-18 Manugistics, Inc. System and method for order group planning with attribute based planning
US20030200130A1 (en) * 2002-02-06 2003-10-23 Kall Jonathan J. Suite of configurable supply chain infrastructure modules for deploying collaborative e-manufacturing solutions

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8626327B2 (en) 2010-11-05 2014-01-07 The Coca-Cola Company System for optimizing drink blends
US8639374B2 (en) 2010-11-05 2014-01-28 The Coca-Cola Company Method, apparatus and system for regulating a product attribute profile
US10261501B2 (en) 2010-11-05 2019-04-16 The Coca-Cola Company System for optimizing drink blends
US10762247B2 (en) 2010-11-05 2020-09-01 The Coca-Cola Company System and method of producing a multi component product
US11048237B2 (en) 2010-11-05 2021-06-29 The Coca-Cola Company System for optimizing drink blends
US11151496B2 (en) 2018-02-19 2021-10-19 Target Brands, Inc. Parallel lead time determinations in supply chain architecture
CN115660389A (en) * 2022-12-27 2023-01-31 惠州市金百泽电路科技有限公司 Automatic processing method and system for PCB project order arrangement
CN115660389B (en) * 2022-12-27 2023-09-15 惠州市金百泽电路科技有限公司 Automatic processing method and system for PCB engineering order

Also Published As

Publication number Publication date
WO2005062771A3 (en) 2005-09-29

Similar Documents

Publication Publication Date Title
Sawik On the risk-averse optimization of service level in a supply chain under disruption risks
Ball et al. Available to promise
Shen Integrated supply chain design models: a survey and future research directions
Hariharan et al. Customer-order information, leadtimes, and inventories
de Kok et al. Planning supply chain operations: definition and comparison of planning concepts
Giri et al. Coordinating a supply chain under uncertain demand and random yield in presence of supply disruption
US7058587B1 (en) System and method for allocating the supply of critical material components and manufacturing capacity
US20040030428A1 (en) System and method for scheduling and sequencing supply chain resources
US8650101B1 (en) Internal material system for facilitating material and asset movement within organizational infrastructures
WO2002035394A1 (en) System and method for inventory and capacity availability management
Jemai et al. Inventory routing problems in a context of vendor-managed inventory system with consignment stock and transshipment
Taaffe et al. Target market selection and marketing effort under uncertainty: The selective newsvendor
Liberatore et al. Supply chain planning: Practical frameworks for superior performance
Saxena Inventory management: Controlling in a fluctuating demand environment
WO2005062771A2 (en) System and method for supply chain management to allow intelligent shipment scheduling that accounts for shortages and delays
Denton et al. Strategic inventory deployment in the steel industry
Gaonkar et al. Strategic sourcing and collaborative planning in Internet-enabled supply chain networks producing multigeneration products
Pradhan Demand and supply planning with SAP APO
Ailawadi et al. Logistics and Supply Chain Management
Tang Perspectives in supply chain risk management: a review
Solo Multi-objective, integrated supply chain design and operation under uncertainty
Pishchulov et al. Inventory rationing and sharing in pre-sell distribution with mobile communication technologies
Banerjee et al. A production capacity optimisation model for a global supply chain coordinator
Malik et al. Supply chain management-an overview
Kurbel et al. Case: SAP SCM

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase in:

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase
122 Ep: pct application non-entry in european phase