Patent Application
20230297946
The field relates generally to information processing systems, and more particularly to automated risk management in such information processing systems.
There are many technical scenarios whereby entities attempt to manage items in their control with a goal of minimizing the risk of one or more negative consequences occurring as the items age. However, such conventional risk management techniques are largely manual and reactive in nature, and thus do not adequately minimize such risk. Illustrative technical scenarios may include use cases wherein the aging item at risk is an electronic data object or a physical part. Regardless, ineffective risk management can have significant negative consequences for an entity.
Illustrative embodiments provide automated risk management techniques in an information processing system.
For example, in an illustrative embodiment, for a given item type obtainable from two or more sources, wherein each of the two or more sources has an aging policy associated with the item type that is different with respect to one another, the method predicts a quantity of the item type obtainable from each of the two or more sources that is at risk during a given future time period based on the aging policy of each of the two or more sources. The method then determines one or more actions to be initiated to mitigate the quantity of the item type obtainable from each of the two or more sources that is at risk during the given future time period.
Advantageously, one or more illustrative embodiments provide automated risk management in a supply chain management environment that predict risk for each part and supplier which may result in negative consequences including, but not limited to, part shortage and/or loss. Based on the predicted risk, consumption shaping and/or return planning can be initiated to mitigate the predicted risk.
These and other illustrative embodiments include, without limitation, apparatus, systems, methods and computer program products comprising processor-readable storage media.
As mentioned, a physical part is one example of an item wherein ineffective risk management of the aging of the physical part can cause negative consequences for an entity. More particularly, a technical scenario in which risk management of a physical part can apply is supply chain management. Supply chain management in the manufacturing industry typically refers to the process of monitoring and taking actions required for a manufacturer, such as an original equipment manufacturer (OEM), to obtain raw materials (i.e., parts), and convert those parts into a finished product (equipment) that is then delivered to or otherwise deployed at a customer site. A goal of supply chain management with respect to the parts is to adequately balance supply and demand, e.g., the supply of the parts (the parts procured or otherwise acquired from vendors, etc.) with the demand of the parts (e.g., the parts needed to satisfy the manufacturing of equipment ordered by a customer). Management of the parts has been a challenge in the traditional and now modern supply chain processes.
Original equipment manufacturers (OEMs) typically procure parts in bulk based on a demand trigger. It is also typical practice for an OEM to source the total quantity needed for a given part type from different suppliers. If a part is not used, different suppliers have different part return policies (aging policies, as illustratively used herein), e.g., some suppliers have a 90-day return policy and some have 120-day return policy. Accordingly, if an unused part is not returned by the OEM to the vendor by the expiration of the return date (e.g., 90 or 120 days from OEM's receipt of the part), then the OEM may not be entitled to a refund (e.g., full or partial). Thus, in this illustrative OEM scenario, the term aging of a part illustratively refers to the length of time, since receipt, that the part has been in the inventory of the OEM without being consumed (e.g., used in an assembled unit of equipment or otherwise in the manufacturing process).
Currently, OEMs use a first-in-first-out (FIFO) consumption model for manufacturing a unit of equipment. That is, they use the earliest-received parts in their inventory and work their way forward in time through subsequently-received parts. OEMs also currently attempt to manually keep track, month-to-month, of the aging of each part, i.e., how long the part has been in the OEM's inventory, against the return policy of the vendor that supplied the part.
However, illustrative embodiments realize herein that the above-mentioned conventional methodology of tracking the aging of a part versus the return policy has several technical problems. By way of example only, there currently is no systematic view of different return policies of different vendors. As such, the procurement team of an OEM ends up missing deadlines for returning unused parts, causing the OEM to unnecessarily incur negative consequences such as, for example, significant costs. Further, current techniques for demand forecasting do not specify how many parts are going to be returned over a future time period (e.g., upcoming yearly-quarter). As such, demand and supply forecasts do not consider returning parts and end up with over stock or with shortages because they do not manage returns properly if at all.
Illustrative embodiments overcome the above and other technical problems by providing an automated risk management system. By way of example,
By way of example, predictive risk management system 120 is configured to predict different returnable parts based on different return policies (i.e., defined as part of aging item related data 122) and adjust demand planning or manufacturing planning to consume the parts in different ways with a goal to have zero or otherwise minimal part returns, and when the goal is predicted to not be achievable, then making preparations in advance for the subsequent return of parts by the deadlines (i.e., as part of risk mitigation plan 124).
Prior to describing illustrative automated risk management systems and methodologies according to illustrative embodiments, some illustrative use cases will be described for context.
Effective management of supply consumption is a technical problem with manufacturing organizations (e.g., OEMs) that procure raw material from suppliers and manufacture equipment using the raw materials. To avoid monopolization of a part, manufacturers source the same part from different suppliers or vendors. For example, an OEM who projects they will need 1000 hard disks for computer equipment they are manufacturing may order (source) 300 hard disks from Supplier 1, 500 from Supplier 2, and 200 from Supplier 3.
The payment and return policies of each supplier can be different. Assume for this example:
The technical problem is that once the parts from the various suppliers arrive at the manufacturing location, all the parts from every supplier go into a common inventory pool. The parts in the single inventory pool are then consumed for manufacturing orders in a FIFO manner, as mentioned above, with little or no regard for the return policy deadlines of each supplier.
With existing management approaches, assume that each month the procurement team views the remaining hard disks, analyzes the number, and returns at least a portion of unused hard disks to their respective suppliers. The first technical problem here is that, since hard disks are consumed in a FIFO manner, the amount remaining for each supplier is not readily visible requiring the procurement team to manually segregate the inventory and decide which hard disks are to be returned.
Further, with existing management approaches, assume at the end of December, the procurement team returns 30 parts to different suppliers. Assume further that the original demand planning and supply planning was done three months earlier in October. Thus, when demand planning occurred, there was no way the order management planner would have known that, at the end of December, 30 hard disks would be returned. Thus, it was assumed that there would be a 54 hard disk surplus at the end of January (given the previously computed demand forecast done in October). However, because a decision was made by the procurement team at the end of December to return 30 hard disks, there is only a 24 hard disk surplus at the end of January. As a result, there is an under-procurement of hard disks which leads to a shortage.
If the order management planner had visibility when demand/supply planning occurred in October that 30 hard disks would be returned at the end of December, they could have done better planning. For example:
Thus, in a supply chain scenario, different suppliers have different return policies (e.g., part life cycle). In existing management approaches, the returns are done on a month-to-month basis based on the current monthly view of remaining parts. As such, it is very difficult to analyze which suppliers and what quantity needs to be returned from the common inventory pool of parts. Incorrect returns lead to part shortages or late returns lead to cost to the organization. Since the order management planner does not have the future view of visibility of different supplier's parts remaining in future months, they cannot make a plan to effectively consume the parts in time using techniques such as part deviation, part substitution, finished goods assembly (FGA) stock, etc.
Accordingly, predictive risk management system 120 of
Similarly, part consumption history data 312 is classified by part (e.g., simple grouping by the part type, e.g., hard disk) in a classification module 314 and then provided, with seasonal variation data 316, to a predicted consumption module 318 which uses one or more artificial intelligence-based (machine learning) models and/or algorithms (e.g., Bayesian model and linear regression) to generate a predicted consumption for each part type, i.e., demand forecast for a given future time period such as, but not limited to, the next yearly-quarter.
An intelligent rule engine 320 maintains the attributes of the return policies (e.g., return deadlines and refund percentages) for the suppliers with a weightage of priority on each supplier (e.g., which supplier will cost the organization more if parts are not returned by the deadline).
The predicted supply from predicted supply module 308 and the demand forecast from predicted consumption module 318 are provided to a predicted balance part calculator 322 which predicts (e.g., using one or more machine learning algorithms/models), for each part type, how many parts will be remaining in the common inventory pool in the given future time period based on the predicted supply and predicted demand.
Based on the predicted remaining parts computed by predicted balance part calculator 322 and data maintained/computed by intelligent rule engine 320, a predicted returnable part calculator 324 predicts (e.g., using one or more machine learning algorithms/models) the number of returnable parts, for each part type, for each supplier.
An order management module 326 queries a demand shaping engine 328 which inputs the predicted number of returnable parts and the demand forecast, and generates a part deviation plan (e.g., instead of using one supplier's part, use another supplier's part) for the existing order to consume parts from suppliers that would have a larger impact on the OEM. The available part deviation options are provided to order management module 326 which can then instruct demand shaping engine 328 to instruct a mitigation engine 330 to implement a selected part deviation, e.g., consume more parts from a given supplier and/or stock parts for future customer orders. Mitigation engine 330 also identifies the parts to return, if any. That is, as mentioned above, a goal is to fully consume parts in the common inventory pool without incurring shortages and/or return policy deadline misses.
Thus, as described above, root data for system architecture 300 of predictive risk management system 120 comprises the history of part shipping from each supplier (302) and the history of consumption of the part (312). Classification of the root data (by modules 304 and 314) is based on the part and region and, in some embodiments, is done by simple grouping. Once grouped by the part, a Bayesian network is used (by modules 308 and 318) with seasonality variations (306 and 316) for forecasting parts available from suppliers (supply) and consumption of the parts in equipment manufacturing (demand).
To further illustrate the technical problems that illustrative embodiments overcome, table 400 in
Using the existing management approach, for the 16 hard disks left in the pool, the procurement team performs analytics and determines that 9 hard disks are sourced from Supplier 1, 3 hard disks are sourced from Supplier 2, and 4 hard disks are sourced from Supplier 3. Now assume they look into the suppliers' return policies and return hard disks for that month to avoid being charged for them. However, as explained above, the procurement team does not know they are misbalancing the demand planning that done for next month. Due to this return, they can cause a parts shortage. However, if they did not return the hard disks that were close to or at the return deadline, it would cause cost to the OEM.
To overcome the technical problems of the existing management approach, system architecture 300 of predictive risk management system 120 utilizes predicted supply module 308 to provide a hybrid prediction approach using a Bayesian model and linear regression.
It is realized that the supply data, i.e., supplier shipping history data 502 and current shipment data 504 can comprise linear data and non-linear data. After pre-processing 506 of the supplier shipping history data 502 and current shipment data 504 to classify the data into linear and non-linear for a specific part and supplier, the linear supply data with seasonality changes is provided to a SARIMA (Seasonal Autoregressive Integrated Moving Average) time series module 508 and the non-linear supply data is provided to a gradient boosting module 510.
SARIMA time series module 508 utilizes machine learning (ML) models (SARIMA models) that are the extension of an ARIMA model that supports univariate time series data involving backshifts of the seasonal period.
Gradient boosting module 510 is an ensemble technique that takes a group of ML models that are weak learners and uses them to create a strong learner. More particularly, gradient boosting module 510 combines weak learners by iteratively focusing on errors resulting at each step until a suitable strong learner is obtained as a sum of the successive weak learners.
Respective outputs of SARIMA time series module 508 and gradient boosting module 510 are provided to a training module 512 and a validation module 514 to support the hybrid prediction. By way of example, training module 512 and validation module 514 may use experiential data from the procurement team to modify and retrain by modifying the average model in time series and validation of the actual output and re-processing for the gradient boosting. A shipping (supply) forecast 516 results from the hybrid prediction process executed in supply prediction architecture 500.
Turning now to predicting the consumption, recall that system architecture 300 of predictive risk management system 120 utilizes predicted consumption module 318 to provide a hybrid prediction approach using a Bayesian model and linear regression.
Consumption prediction architecture 700 inputs part consumption history 702 (312 in
It is realized herein that since the pool contains all suppliers' parts and each supplier's return policy is different, the order management team cannot treat all of these with the same strategy for different consumptions to manage the pool to zero (or near zero). As such, the predicted contribution by each supplier in the effective pool is determined as illustrated portion 902 of table 900 of
Currently, the procurement team uses a statistical method for the current month. As given in the data of table 900, the current month Effective Pool is 16, and each supplier data is 9, 3 and 4, respectively. Thus, the system tries to find the trending ratio of suppliers over a time period. If consumption uses the parts in the same ratio of purchase, then the purchase ratio can be used. However, some OEMs employ a common pool and use FIFO-based consumption. So, the consumption depends on the shipment from the supplier. But in this case, if the trend of remaining parts over a month can be obtained, the ratio prediction can be obtained. Once the prediction of the ratio is obtained (in this example, the ratio is 3:4:3), portion 902 shows the predicted consumption based on supplier over the given future time periods (e.g., upcoming 5 months). Returning to
Since the system handles consumption in a FIFO manner, it will instruct to consume first shipment parts and then second shipment parts at some point of time. Intelligent rule engine 320 converts the policies as follows:
Supplier 1 policy converts (Return policy less than 90 days) to a rule as follows:
Supplier 2 policy converts (Return policy less than 30 days) to a rule as follows:
Supplier 3 policy converts (Return policy less than 120 days) to a rule as follows:
As per the data in the
Illustrative embodiments are described herein with reference to exemplary information processing systems and associated computers, servers, storage devices and other processing devices. It is to be appreciated, however, that embodiments are not restricted to use with the particular illustrative system and device configurations shown. Accordingly, the term “information processing system” as used herein is intended to be broadly construed, so as to encompass, for example, processing systems comprising cloud computing and storage systems, as well as other types of processing systems comprising various combinations of physical and virtual processing resources. An information processing system may therefore comprise, for example, at least one data center or other type of cloud-based system that includes one or more clouds hosting tenants that access cloud resources. Cloud infrastructure can include private clouds, public clouds, and/or combinations of private/public clouds (hybrid clouds).
The processing platform 1100 in this embodiment comprises a plurality of processing devices, denoted 1102-1, 1102-2, 1102-3, . . . 1102-K, which communicate with one another over network(s) 1104. It is to be appreciated that the methodologies described herein may be executed in one such processing device 1102, or executed in a distributed manner across two or more such processing devices 1102. It is to be further appreciated that a server, a client device, a computing device or any other processing platform element may be viewed as an example of what is more generally referred to herein as a “processing device.” As illustrated in
The processing device 1102-1 in the processing platform 1100 comprises a processor 1110 coupled to a memory 1112. The processor 1110 may comprise a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other type of processing circuitry, as well as portions or combinations of such circuitry elements. Components of systems as disclosed herein can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device such as processor 1110. Memory 1112 (or other storage device) having such program code embodied therein is an example of what is more generally referred to herein as a processor-readable storage medium. Articles of manufacture comprising such computer-readable or processor-readable storage media are considered embodiments of the invention. A given such article of manufacture may comprise, for example, a storage device such as a storage disk, a storage array or an integrated circuit containing memory. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals.
Furthermore, memory 1112 may comprise electronic memory such as random-access memory (RAM), read-only memory (ROM) or other types of memory, in any combination. The one or more software programs when executed by a processing device such as the processing device 1102-1 causes the device to perform functions associated with one or more of the components/steps of system/methodologies in
Processing device 1102-1 also includes network interface circuitry 1114, which is used to interface the device with the networks 1104 and other system components. Such circuitry may comprise conventional transceivers of a type well known in the art.
The other processing devices 1102 (1102-2, 1102-3, . . . 1102-K) of the processing platform 1100 are assumed to be configured in a manner similar to that shown for computing device 1102-1 in the figure.
The processing platform 1100 shown in
Also, numerous other arrangements of servers, clients, computers, storage devices or other components are possible in processing platform 1100. Such components can communicate with other elements of the processing platform 1100 over any type of network, such as a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, or various portions or combinations of these and other types of networks.
Furthermore, it is to be appreciated that the processing platform 1100 of
As is known, virtual machines are logical processing elements that may be instantiated on one or more physical processing elements (e.g., servers, computers, processing devices). That is, a “virtual machine” generally refers to a software implementation of a machine (i.e., a computer) that executes programs like a physical machine. Thus, different virtual machines can run different operating systems and multiple applications on the same physical computer. Virtualization is implemented by the hypervisor which is directly inserted on top of the computer hardware in order to allocate hardware resources of the physical computer dynamically and transparently. The hypervisor affords the ability for multiple operating systems to run concurrently on a single physical computer and share hardware resources with each other.
It was noted above that portions of the computing environment may be implemented using one or more processing platforms. A given such processing platform comprises at least one processing device comprising a processor coupled to a memory, and the processing device may be implemented at least in part utilizing one or more virtual machines, containers or other virtualization infrastructure. By way of example, such containers may be Docker containers or other types of containers.
The particular processing operations and other system functionality described in conjunction with
It should again be emphasized that the above-described embodiments of the invention are presented for purposes of illustration only. Many variations may be made in the particular arrangements shown. For example, although described in the context of particular system and device configurations, the techniques are applicable to a wide variety of other types of data processing systems, processing devices and distributed virtual infrastructure arrangements. In addition, any simplifying assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the invention.
