WO2020086872A1 - Procédé et système de génération de prévisions de demande d'ensemble - Google Patents

Procédé et système de génération de prévisions de demande d'ensemble Download PDF

Info

Publication number
WO2020086872A1
WO2020086872A1 PCT/US2019/057899 US2019057899W WO2020086872A1 WO 2020086872 A1 WO2020086872 A1 WO 2020086872A1 US 2019057899 W US2019057899 W US 2019057899W WO 2020086872 A1 WO2020086872 A1 WO 2020086872A1
Authority
WO
WIPO (PCT)
Prior art keywords
forecast
data
demand
validation
model
Prior art date
Application number
PCT/US2019/057899
Other languages
English (en)
Inventor
Adam Morgan
Anand Das
Samir H. Shah
Phillip YELLAND
Original Assignee
Target Brands, Inc.
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
Priority claimed from US16/172,575 external-priority patent/US11373199B2/en
Priority claimed from US16/172,588 external-priority patent/US11295324B2/en
Priority claimed from US16/172,603 external-priority patent/US11170391B2/en
Application filed by Target Brands, Inc. filed Critical Target Brands, Inc.
Publication of WO2020086872A1 publication Critical patent/WO2020086872A1/fr

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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0202—Market predictions or forecasting for commercial activities
    • 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/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"

Definitions

  • the present disclosure relates generally to methods and systems for forecasting demand for items. More specifically, methods and systems are provided for generating demand forecasts for items based on past sales data and past demand forecasts.
  • Demand forecasting involves predicting future demand for products or services of a business or organization.
  • Demand forecasting produces valuable information for businesses to use in production planning, inventory management, staff scheduling, and supply chain management. It is important to know how much inventory is needed to order and stock at various locations of a retail chain.
  • Demand forecasting information can be useful not only for inventory management, but for scheduling personnel, planning marketing events, and budgetary planning.
  • the present disclosure relates to methods and systems for forecasting item demand in a retail context.
  • Various aspects are described in this disclosure, which include, but are not limited to, the following aspects.
  • a system for forecasting demand for a plurality of items includes a common data preparation engine.
  • the common data preparation engine includes a computing system including a data store, processor, and memory communicatively coupled to the processor, the memory storing instructions executable by the processor to: receive sales data, convert sales data to common format data, and store common format data in a standard data store.
  • the system also includes an enterprise forecast engine.
  • the enterprise forecast engine includes a computing system including a processor, and a memory communicatively coupled to the processor, the memory storing instructions executable by the procssor to: build a forecasting model; access the common format data; generate an aggregate demand forecast using the forecasting model and the common format data; and communicate the aggregate demand forecast to a forecasts data store for storage.
  • the system further includes a server comprising an application programming interface (API) accessible by one or more client applications, the API configured to: receive demand forecast requests, communicate demand forecast requests to the forecasts data store, and receive aggregate demand forecasts from the forecasts data store.
  • the forecasting model is an ensemble forecast model built by selecting two or more component models used to forecast demand for items and weighting the two or more component models based on past forecasting performance.
  • the ensemble forecast model is calculated using an affine function.
  • the component models include one or more of an ARIMA model or a LOESS model.
  • the forecasting model is a single model based on a recurring neural network (RNN).
  • the API is further configured to generate an administrator user interface for visualizing demand forecast data.
  • the system further comprises a cloud platform with at least one load balancer to direct requests to available servers for processing.
  • the past forecasting performance is evaluated by a forecast validation engine.
  • a method of forecasting demand for a plurality of items within a retail enterprise is disclosed.
  • the method includes receiving sales data at a common data preparation engine, formatting the sales data into a common format, and building, with an enterprise forecast engine, an ensemble forecast model from two or more component models.
  • the method further includes analyzing, with the ensemble forecast model, the common format sales data to generate an aggregate demand forecast, and storing the aggregate demand forecast in a forecasts data store.
  • the method further comprises: receiving, at an API, a request from a client application for a demand forecast;
  • building further comprises weighting the two or more component models based on past performance of the component models in predicting item demand.
  • the demand forecast is generated for an individual item, over a 1 week time period, for all sales of the retail enterprise.
  • the request comprises a time period, a location, and one or more items.
  • the request is communicated to the data store by a real-time query service.
  • the demand forecast is visualized on a user interface for viewing and analysis by an administrator user.
  • the method further comprises: validating the ensemble forecast model by: receiving a validation and selection of configuration options at a command line tool; sending a submission packet to a validation server; querying the forecasts data store; storing a validation set in a data repository; calibrating the ensemble forecast model with historical training data; testing the ensemble forecast model by calculating predicted values for each of a set of forecast coordinates; saving the predicted values; calculating forecast validation results; storing the forecast validation results in data repository; and displaying a visualization of forecast performance on a validation user interface.
  • a non-transitory computer-readable storage medium comprising computer-executable instruction which, when executed by a computing system, cause the computing system to perform a method of generating a demand forecast for one or more items.
  • the method includes receiving store sales data and web sales data at a common data preparation engine, and formatting the store sales data and web sales data into a common format.
  • the method also includes building, with an enterprise forecast engine, an ensemble forecast model from two or more component models, and analyzing, with the ensemble forecast model, the common format data to generate a demand forecast, as well as storing the aggregate demand forecast in a forecasts data store.
  • the method further includes receiving, at an API, a request from an administrator computing device for a demand forecast, communicating the request to the forecasts data store, and communicating the demand forecast to a user interface on the administrator computing device.
  • the method includes visualizing the demand forecast on a display of the administrator computing device.
  • building the ensemble forecast model comprises: receiving parameters for a demand forecast; selecting component models based on past performance; weighting the component models based on past performance; and calculating the ensemble forecast using an affine function.
  • FIG. 1 illustrates a schematic diagram of an system for forecasting item demand in a retail context
  • FIG. 2 illustrates an example block diagram of a computing system usable in the system of FIG. 1;
  • FIG. 3 illustrates a more detailed schematic diagram of the demand forecasting system of FIG. 1;
  • FIG. 4 is a flow chart of an example method of forecasting item demand
  • FIG. 5 shows a more detailed schematic diagram of the common data prep engine and enterprise forecast engine of FIG. 3;
  • FIG. 6 is a flow chart of an example method of building an ensemble forecasting model
  • FIG. 7 shows a more detailed schematic diagram of the forecast validation engine of FIG. 3;
  • FIG. 8 is a flow chart of an example method of validating a forecasting model
  • FIG. 9 illustrates an example user interface for validating forecasting models
  • FIG. 10 illustrates a more detailed view of the filter section of the example user interface of FIG. 9;
  • FIG. 11 illustrates a more detailed view of the sets section of the example user interface of FIG. 9;
  • FIG. 12 illustrates a more detailed view of the options section of the example user interface of FIG. 9;
  • FIG. 13 illustrates a more detailed view of the plot section of the example user interface of FIG. 9;
  • FIG. 14 illustrates a more detailed view of the details section of the example user interface of FIG. 9;
  • FIG. 15 is a flow chart of an example method of disaggregating an aggregate demand forecast.
  • the present disclosure relates to methods and systems for forecasting demand for a plurality of items.
  • the demand forecasting system and methods described herein are useful for predicting demand of products in a retail context.
  • An ensemble forecast is compiled using component models that are combined and weighted to produce a consensus forecast for predicting item demand.
  • Past forecasting performance is evaluated to determine which models are best used for particular sets of items. Models having superior performance for predicting item demand are weighted more heavily in the overall consensus forecast.
  • Forecast models are validated by evaluating actual demand vs. predicted demand and using that information to inform how a future ensemble forecast will be generated.
  • the present methods have an improved ability to capture seasonal effects on demand such as holiday sales or back to school sales.
  • the systems and methods are scalable and customizable to different applications of the forecast data. For example, a forecast may be generated on a weekly basis at the chain level for a group of retail stores. However, the forecast can be broken down to an individual store or an individual date.
  • FIG. 1 illustrates a schematic diagram of an example computing network 100 used in the operation of a retail chain.
  • a retailer server system 102, an administrator computing device 106, and a demand forecasting system 108 are in communication through a network 110.
  • the network 110 may also be in
  • the administrator computing device 106 communicates with the demand forecasting system 108 through the network 110 to request demand forecasts, evaluate forecasts generated by the demand forecasting system 108 and visualize those results.
  • the requesting, evaluating, and visualizing may occur with the assistance of a user interface 112 displayed on the administrator computing device 106.
  • the computing system 106 includes at least one central processing unit (“CPU”) 202, a system memory 208, and a system bus 222 that couples the system memory 208 to the CPU 202.
  • the system memory 208 includes a random access memory (“RAM”) 210 and a read-only memory (“ROM”) 212.
  • RAM random access memory
  • ROM read-only memory
  • the computing system 106 further includes a mass storage device 214.
  • the mass storage device 214 is able to store software instructions and data.
  • the mass storage device 214 is connected to the CPU 202 through a mass storage controller (not shown) connected to the system bus 222.
  • the mass storage device 214 and its associated computer-readable storage media provide non volatile, non-transitory data storage for the computing system 106.
  • computer-readable storage media can include any available tangible, physical device or article of manufacture from which the CPU 402 can read data and/or instructions.
  • the computer- readable storage media comprises entirely non-transitory media.
  • Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable software instructions, data structures, program modules or other data.
  • Example types of computer-readable data storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROMs, digital versatile discs (“DVDs”), other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computing system 106.
  • the computing system 106 may operate in a networked environment using logical connections to remote network devices through a network 222, such as a wireless network, the Internet, or another type of network.
  • the computing system 106 may connect to the network 222 through a network interface unit 404 connected to the system bus 422.
  • the network interface unit 404 may also be utilized to connect to other types of networks and remote computing systems.
  • the computing system 200 also includes an input/output controller 206 for receiving and processing input from a number of other devices, including a touch user interface display screen, or another type of input device. Similarly, the input/output controller 206 may provide output to a touch user interface display screen or other type of output device.
  • the mass storage device 214 and the RAM 210 of the computing system 106 can store software instructions and data.
  • the software instructions include an operating system 418 suitable for controlling the operation of the computing system 106.
  • the mass storage device 414 and/or the RAM 410 also store software instructions, that when executed by the CPU 402, cause the computing system 106 to provide the functionality discussed in this document.
  • the mass storage device 414 and/or the RAM 410 can store software instructions that, when executed by the CPU 402, cause the computing system 106 to receive and analyze inventory and demand data.
  • FIG. 3 illustrates a detailed schematic of the demand forecasting system 108.
  • the components of the demand forecasting system 108 include a common data preparation engine 302, an enterprise forecast engine 304, a forecast validation engine 306, a forecasts data base 310, a forecasts data store 312, one or more resource managers 314, and a cloud platform 322 including one or more load balancers 340 and a plurality of servers 330.
  • the components of the demand forecasting system 108 are described in detail with reference to the method 400 of FIG. 4.
  • FIG. 4 illustrates an example flow chart of a method 400 of forecasting demand that may be implemented by the demand forecasting system 108 of FIG. 3.
  • the common data preparation engine 302 receives and prepares past sales data and past demand forecasts.
  • the common data preparation engine 302 receives and prepares both past data and incoming current data.
  • the data can include sales activity as well as other data regarding attributes of items, stores, and locations.
  • the data is processed into a common format for use by the enterprise forecast generator 304.
  • a more detailed view of a schematic of the common data preparation engine 302 is depicted in Figure 5.
  • a demand forecasting model is built.
  • forecasts are generated using a single model, such as a recurrent neural network (RNN) model.
  • RNN recurrent neural network
  • an enterprise“consensus” model is built from combining two or more component models. Methods of building forecasting models are further described in FIG. 6.
  • the forecasting models are typically built using python or R software programming languages.
  • the component models are generally selected from time series forecasting models such as recurrent neural network (RNN) models or Autoregressive integrated moving average models (ARIMA), seasonal trend decomposition by LOESS (STL).
  • RNN recurrent neural network
  • ARIMA autoregressive integrated moving average models
  • STL seasonal trend decomposition by LOESS
  • the component models are fed into a meta-forecaster to produce a compounded or consensus forecast.
  • weighting of the component models is done based on an affine function equation.
  • the past performance of the component models is assessed for accuracy in forecasting. Accuracy alone is not the most important aspect but capturing seasonal effects can also be important.
  • the models having the best performance for predicting demand are weighted more heavily and used in combination to predict the latest demand forecast. The weighted combination provides a more accurate representation of demand than any individual component model.
  • the weighting of the models can change throughout the year based on, e.g., promotions or seasonality.
  • the model is validated at the forecast validation engine 306 of FIG. 3.
  • the model is tested for its ability to forecast item demand using past data for testing.
  • the validation process is further described in reference to FIG. 8 and the forecast validation engine 306 is further described in detail in FIG. 7.
  • an aggregate demand forecast is generated.
  • the enterprise forecast engine 304 generates demand forecasts in batches by default. In one embodiment, forecasts are generated for each item, across all stores in a retail chain, every week.
  • the aggregate forecasts are stored in a data store.
  • the forecasts are communicated to a forecasts database 310.
  • the forecasts database 310 utilizes Apache Hive tables for storing the aggregate forecasts.
  • the forecasts database 310 is set up to effectively handle batch data uploads. Periodically, the data from the forecasts database 310 is uploaded to the forecasts data store 312.
  • the forecasts data store 312 utilizes Apache HBASE to store the aggregate forecasts.
  • the forecasts data store 312 is set up to effectively handle real-time data queries from clients.
  • a request for a demand forecast is received from a client.
  • the client request is received at a cloud platform 322 including one or more load balancers 324, as shown in FIG. 3.
  • the load balancers 324 route the request to one of a plurality of servers 330 to process the request for a demand forecast.
  • Requests are received from clients which can include other computing applications within a retailer network such as an inventory planning application, staffing planning application, or other supply chain application.
  • the demand forecasting system 108 utilizes a plurality of servers 330.
  • the load balancers 324 operate to direct queries from a client 326 to a server 330 that is the least busy with processing other requests or queries.
  • a single server 330 could be utilized in the system. However, for large quantities of items for a large retailer having multiple locations, having multiple servers 330 is beneficial for efficiency of processing queries.
  • multiple servers 330 are managed by a cloud platform 322 such as those available from Apache OpenStack.
  • An HAProxy load balancer 324 could be used to distribute queries to different servers 330.
  • Each server 332 has a copy of the needed services or applications for the demand forecasting system 108 to operate efficiently.
  • each server 330 includes an API (application programming interface) 332, a CDF (cumulative distribution function) 334, and a disaggregation service 336.
  • the API 332 operates to breakdown requests received from clients and communicate requests for data to a data source such as the forecasts data store 312.
  • the API 332 is accessible by one or more client applications for use in various analyses for the retailer.
  • the API may be accessed through a user interface by an administrator computing device. An administrator user interacts with the user interface using inputs and outputs of the administrator computing device.
  • a query is received from a client at the API, e.g., as routed from the load balancer 324.
  • the query includes one or more of an item or set of items, a location, a starting time and a time period; other parameters could be included as well, to the extent exposed by the API. For example, the query could be for a weekly forecast in September for all stores in Minnesota.
  • the API can also receive a selection of a particular model or model collection with which to forecast demand.
  • Once the API receives the client request it is broken down to determine which data is needed to satisfy the query.
  • the query service 318 is accessed which then accesses the forecasts data store 312 to retrieve the chain level forecast or“aggregate demand forecast.”
  • the CDF 334 breaks down the forecast to a distribution.
  • the API 332 communicates the requested demand forecast back to the client application. In some embodiments, this involves presenting the requested demand forecast data on a user interface.
  • the API (application programming interface) 332 operates to receive client requests in real-time. Each API 332 responds to clients 326 on a per-request basis. In some embodiments, the API 332 communicates with the forecasts data store 312 through a resource manager 314. Each resource manager 314 includes an application master 316 and a query service 318. The query service 318 retrieves the requested data from the forecasts data store 312.
  • the resource manager 314 may be built using open-source software such as Apache SLIDER.
  • the cloud platform 322 may be built using Apache OpenStack.
  • each application or service within the server 330 may be packaged into a docker container using an Apache Tomcat service.
  • the aggregate demand forecast is disaggregated, if needed. This can be accomplished via a disaggregation service 336available at each server 330.
  • the disaggregation service 336 operates to break down aggregate demand forecasts retrieved from the forecasts data store 312 into smaller units of location or time, depending on the client request. Not every request will require disaggregation, but the API processes the request to determine if disaggregation is needed to properly respond to the request.
  • the disaggregation service 336 is further described in relation to FIG. 15.
  • the forecast is converted to a distribution by the CDF 334 if needed.
  • each server 330 includes a CDF
  • This service operates to convert aggregate demand forecasts retrieved by the API into forecast distributions. Not every client request will involve forecast distributions, but for those that do, the API determines that a distribution is needed and communicates with the CDF service 334 to manage that calculation.
  • the demand forecast is output to the client in response to the client’s request.
  • the client is an administrator user interface and the demand forecast is visualized for viewing, for example, by an administrator user.
  • FIG. 5 illustrates a more detailed schematic diagram of the common data prep engine 302 and enterprise forecast engine 304.
  • the common data preparation engine 302 receives and prepares data from a retail entity for processing by the enterprise forecast engine 304 in order to generate demand forecasts for the retail entity.
  • the common data preparation engine 302 includes a memory 502 in communication with a processor 504.
  • the memory 502 includes software applications including a data preparation application 512.
  • the memory also includes data stores or databases including a standard data store 514.
  • the data preparation application 512 operates to receive data from a retailer that may include catalog data, location data, inventory data, promotion data, planogram data, web sales data, and store sales data. In some embodiments, this data may first be gathered at a server system such as the retailer server system 102 of FIG. 1. This data may be stored permanently in the historical data store 114 or temporarily in the current data repository 116.
  • the data preparation application 512 may receive data in a variety of formats. Before being accessed by the forecast generator 304, the data received at the common data preparation engine 302 may need to be reformatted for use by the forecast generator 304.
  • the data preparation application 512 operates to standardize the data received so that it may be used by a variety of forecasting models at the forecast generator 304. Preferably, the data signals are converted to a format that has the right balance between standardization and flexibility, as different models utilize data in different ways.
  • the data preparation application 512 overcomes challenges of both scale and flexibility. For retailers having a multitude of retail locations and items, it can be difficult to manage massive amounts of data in different formats.
  • the data preparation application 512 also overcomes challenges relating to providing a common view of data for all forecasting models that may access the data for processing.
  • the common data preparation engine 302 saves the processed data from the data preparation application 512 in a standard data store 514.
  • the standard data store 514 stores the standardized data utilizing data warehouse software that provides capabilities for data summarization, theory, and analysis.
  • data warehouse software is Apache Hive.
  • the common data preparation engine 302 processes both building and scoring data. Building data includes past data that is used for building demand forecasting models. Store history and web history are processed at the common data preparation engine 302 for later access by the forecast generator 304 for training various types of demand forecasting models.
  • Data that is currently being received from store and web sales are processed at the common data prep engine 302 and are forwarded to the enterprise forecast generator 304 where that data is used to generate store forecasts and web forecasts. This data is used for scoring or predicting future demand.
  • the common data preparation engine 302 processes incoming data incrementally. Data stores in the standard data store 514 are updated as new data is received instead of processing all data each time new data is received.
  • the standard data store 514 compiles received and processed data into Hive data tables for later access by the forecast generator.
  • Other examples of data that may be received from the internal systems of the retailer include price data, characteristics of retail stores, and calendar event such as holidays.
  • the enterprise forecast engine 304 includes a models database, a model selection and validation engine, day forecast generator, a memory, and a processor.
  • FIG. 6 illustrates a flowchart of a method 404 of generating item demand forecasts.
  • the enterprise forecast engine 304 utilizes one or more models to analyze data received from the common data preparation engine 302.
  • the enterprise forecast engine 304 utilizes one main model based on a recurring neural -network (RNN).
  • RNN recurring neural -network
  • supplemental models such as an ARIMA or LOESS model can be used in conjunction with the RNN model to accommodate for changes in demand caused by seasonality, holidays, or other variations in demand.
  • a meta forecaster makes consensus forecasts for item demands based on an ensemble of component models that are weighted to produce an ensemble model.
  • An ensemble model is constructed around a linear regression of actual demand on demand forecasts produced by component models used to build the ensemble model. Linear regression has the advantages of simplicity, diagnose ability, and familiarity. It may be adapted to emulate other approaches, such as variance weighted combinations or stacked regressions.
  • the demand forecasting system utilizes an enterprise forecast engine that utilizes an ensemble of component models to predict future demand for items.
  • the enterprise forecast engine calculates a linear regression of actual demand on demand forecasts produced by the component models in the ensemble.
  • Linear regression has the advantages of simplicity, diagnosability and familiarity. It may be adapted to emulate other approaches, such as variance- weighted combinations or stacked regressions. Linear regression can be extended to implement more elaborate ensembling approaches.
  • the ensemble model utilizes a weighted combination of two or more component models producing a more accurate representation of demand than any individual component model.
  • the weighted combinations of models are adjusted over time, increasing accuracy as more data is analyzed.
  • FIG. 6 illustrates one example of how an ensemble model is built.
  • parameters for a demand forecast are received at a forecast generator.
  • Parameters can include one or more of a group of items, a time period, a location, and other attributes. For example, parameters may dictate whether the items to be analyzed are on promotion or off promotion. In another example, the time of year could be during a particular season or not.
  • component models are selected based on past performance.
  • Add operation 606 the component models are weighted based on the past performance of the component models for the selected parameters.
  • a forecast validation engine 306 evaluates models for their ability to predict demand for items for given time periods and locations. The demand forecasting models are being evaluated on a continuous basis using new data from the retailer as it is generated. Therefore, the forecasting models are also being continually evaluated and updated. As new data is being ingested and analyzed, the overall ensemble model may be updated by choosing different component models or modifying the weighting of the different component models.
  • the demand forecaster utilizes a single model.
  • the forecasting model may be supplemented by one or more component models to accommodate for seasonality or promotions.
  • a single model is implemented by the demand forecaster, a recurring neural network (RNN) is utilized.
  • RNN recurring neural network
  • Supplemental models can include ARIMA, LOESS or STL (seasonal
  • Seasonal demand can be difficult to predict.
  • a component model that is useful for computing seasonal item demand is a wavelet decomposition model WD.
  • the wavelet decomposition model uses wavelet functions e.g. Haar, Symmlet, Daubechies, etc.
  • wavelet functions e.g. Haar, Symmlet, Daubechies, etc.
  • Multi-level wavelet decomposition is performed on time series data to find approximation and detail coefficients the number of decomposition level depends on the length of the time series data.
  • the maximum decomposition level approximation coefficient is used to reconstruct the time series and the reconstructed time series data will be used as trend. Then the actual time series data is detrended using the trend values found.
  • Seasonal indices are calculated by weighted average based on variance using respective weeks indices from trended data.
  • Another example of a component model useful for computing seasonal item demand uses a combination of spline and GBM decomposition methods.
  • trend estimates can be found by fitting a smoothing spline to the time series.
  • a smoothing parameter is set to a lower bound in order to avoid overfitting and is determined by cross validation.
  • the time series is detrended using the trend values found.
  • the seasonal indices are found by fitting a GBM to the detrended data.
  • coefficients are in turn affine functions of features of the forecast period.
  • the value of feature in week t might represent a promotion
  • FIG. 7 illustrates a detailed schematic diagram of the forecast validation engine 306 of FIG. 3.
  • the forecast validation engine 306 includes a validation server 702, a command line tool 704, and a test directory 706.
  • the forecast validation engine 306 operates to evaluate and validate models built to forecast demand.
  • the forecast validation engine 306 runs multiple forecasts for the same set of sales data and store the results in a table. Metrics are run on the table to cross-validate distributions. The metrics may be entered by an administrator user or selected from a menu.
  • the validation server 702 includes a data repository 710 and a validation user interface 712.
  • the data repository 710 stores forecast validation results obtained from forecasting models used in the demand forecasting system 108.
  • the validation user interface 712 is accessible from an administrator computing device such as the administrator computing device 106 of FIG. 1.
  • the validation user interface 712 allows a user to access a variety of visualization tool to assist with the inspection and visualization of forecast validation results.
  • the command line tool 704 operates to receive uploaded validation sets and prepare them for the validation server 702.
  • FIG. 8 illustrates a flow chart of an example method 406 of validating and visualizing a demand forecasting model. In some aspects, this method is performed by the forecast validation engine 306 of FIGs. 3 and 7.
  • a validation set and accompanying configuration options are received at the command line tool 704.
  • An administrator user may upload the validation set through interactions with the validation user interface 712.
  • the validation set is a data set of forecasted values calculated by the forecasting model to be validated.
  • Configuration options include identifying tags, and selecting metrics to be examined.
  • a submission packet including the validation set, selected configuration options, and identifying information for the data set is sent to the validation server 802.
  • the validation server 702 carries out a series of checks to ensure that the submission packet has the information required for the validation server 802 to perform its analysis.
  • the validation server 702 queries the forecasts data store 312 to retrieve the forecast data generated by the forecasting model being validated.
  • the validation set is stored in the data repository 810.
  • the model is calibrated using historical training data 716 from the test directory 706.
  • the historical training data 716 includes values of the forecast quantity.
  • the test directory 706 also stores ancillary data that may be relevant to the model such as item features, holiday information, seasonal information, etc.
  • the model is tested by calculating predictions for each set of forecast coordinates.
  • the calculated predictions for the set of forecast coordinates can be compared to known data or to other forecasts to determine differences between such results (e.g., to determine outliers or variance outside a threshold.
  • the predicted values 718 are saved in the test directory 706.
  • the predicted values can be saved in various forms, including in a database, or any other convenient file format useable for analysis.
  • Forecast validation results are calculated at the validation server 702 and are stored in the data repository 710.
  • Forecast validation nresults can be, as noted above,
  • the forecast validation engine 306 includes a validation user-interface 712.
  • Figure 9 depicts an example validation user-interface 712.
  • This user interface provides a web-based front-end viewable in a browser window that allows uploaded validation sets to be examined and compared using a range of visualizations.
  • the display is divided into five collapsible sections. Each section is discussed in greater detail in FIGs. 10-14.
  • the sections include a filter 902, sets 904, options 906, plot 908, and details 910.
  • the filter section 902 allows the user to select uploaded validation sets with specific tags, such as user or model and or uploaded before/after a given date.
  • the filter section includes subsections for work stream 914, user 916, model 918, and submit date range 920. Each subsection includes a drop-down list 924 and a tag editor 926. Elements can be selected from the drop-down list or typed into the tag editor text input fields.
  • Tags are selected to filter validation sets.
  • the tag values are drawn from a repository.
  • the tags of all filtered validation sets must equal one of the values in all of the tag editors with at least one value. In the example shown in FIG.
  • validation sets with the work stream tag set to item demand and model tagged either ANM error or ANM-DFE will be selected.
  • the two input fields under submit date range specify an inclusive range of dates restricting dates on which the filtered sets were uploaded. Pressing the filter button 1930 retrieves validation sets from the repository that satisfy the conditions in the tag editors and date input fields summaries of the retrieve sets appear in the table described in the next section.
  • FIG. 11 displays a more detailed view of the sets section 904.
  • the sets section provides a summary table that displays the filtered validation sets from the repository. One or two validation sets can be selected for inspection or comparison.
  • Each row of the table 934 displayed in the sets section 904 represents a validation set in the repository that is filtered according to any criteria stipulated in the filter section 902.
  • Each row of the table 934 includes information describing the validation set including user, model, work stream, check out time, submit time, and ID number.
  • the ID number is a unique number generated upon upload of the validation set.
  • a validation set can be selected from the table by clicking on the corresponding row and clicking the add button 938 to make it available for visualization. Once a set is added, its ID appears in the editor field 936 below the table. In this example, up to two validation sets can be selected at one time.
  • the options section 906 allows a user to choose particular parts of the validation set or sets to inspect and to set options for those visualizations.
  • the option section 906 allows a user to select aspects of the validation set for scrutiny, as well as the visualization to be used in options to be applied to the chosen visualization.
  • the metric selector 942 selects one of the metrics contained in the chosen validation set.
  • a user has selected absolute percentage error (APE).
  • APE absolute percentage error
  • the slice selector 944 includes two lists allowing a user to restrict the visualization to a subset of the metric values recorded in the validation sets. Restricting the validation set to two dimensions restricts attention to the metric values associated with those dimensions. Further restrictions can be added by selecting values for additional dimensions. The resulting restrictions are displayed below the lists.
  • the visualization has been restricted to APE values in department three for promotional items.
  • a series of visualization tabs 946 show available
  • the available visualizations may change depending on the number of validation sets chosen and the number of slices chosen. Selecting a visualization tab 946 displays the settings for that visualization. In the example of FIG. 12, the available visualization tabs include histogram, Q-Q plot, box plot, table 1, and table 2. In this example, the settings displayed show dimensions for class and horizon. Additionally, a logarithmic button is displayed to modify the visualization.
  • FIG. 13 displays a more detailed view of the plot section 908.
  • the plot section provides a display of the selected visualization for the chosen parts of the validation sets.
  • the currently selected and configured visualization is displayed as applied to the selected validation set or sets and restricted according to the selected slice or slices.
  • a box plot 950 is displayed for the dimensions of APE by horizon. Selecting the refresh button 952 plots the visualization.
  • any existing plot becomes partially obscured in the view as it becomes invalidated. Selecting the refresh button 952 will plot the updated selections.
  • FIG. 14 displays a more detailed view of the details section 910 which shows, in tabular form, the data utilized in the visualization.
  • a details table 956 is displayed including the information displayed in the plot section 908 visualization.
  • the fetch button 958 retrieves the table data and updates the details table 956 after any changes of selections made in the options section 906, set section 904, or filters section 902.
  • one or more export buttons 960 may be selected to export the details table 956.
  • the export buttons 960 include an option to export the details table 956 to excel or CSD. A user could also select an export button 960 to print the details table 956.
  • Sales data for individual stores on individual days can be very noisy because for any given item, the sales may be very low. If the number of sales over a particular time interval is too small, estimating the underlying rate of sales is extremely difficult, and the noise properties do not satisfy the requirements of many regression and machine learning techniques used for forecasting. For most items, aggregation at some level is necessary, especially for slow-selling items, in order to ensure sufficient counts within each location/time/item to satisfy the underlying model assumptions.
  • Another problem with forecasting based on individual item, at individual store, on individual day is that it would take much more storage space to store the demand forecasts generated for that level of granularity. It is advantageous to aggregate the data when the number of items being offered by the retail are very high so that data storage space can be conserved.
  • Sales can be aggregated based on location (useful to determine high precision in time), time (useful to determine high location-level precision), and collection of items (useful as a prior for new items). In one embodiment, sales are aggregated to generate forecasts for each item for a week across all stores in the retail chain.
  • the disaggregation service estimates contributions from individual stores. To estimate the count rates at a high granularity among the dimensions of item, location, and day, the behavior over multiple aggregation dimensions is measured and interpolated. For example, the relative sales rates of an item for each store can be determined aggregating the sales over several months, which can then be combined with item/day/chain level forecasts (aggregated over all stores) to estimate the forecast for each individual store.
  • FIG. 15 provides a flow chart of a method 416 of disaggregating an aggregate demand forecast to fulfill a client request.
  • the disaggregation service 336 operates to break down aggregate demand forecasts into demand forecasts for shorter time periods or a smaller number of locations.
  • the forecast generator 304 produces demand forecasts for an entire retail chain of stores, for a week time period, for each individual item. In instances when a client requests a demand forecast for a particular day or a particular store, the disaggregation service 336 computes the demand forecast based on the aggregate demand forecasts stored in the forecasts data store 312.
  • a client request is received and processed.
  • the server 330 receives the client request from the load balancer 324.
  • the API 332 then processes the request to determine which data is needed to satisfy the request, and whether that data needs to be transformed in any way.
  • the API 332 can determine which aggregate demand forecast to request.
  • the API 332 also determines if the forecast requires disaggregation. In the example method of FIG.
  • the API 332 submits a query for the appropriate aggregate demand forecast.
  • the query is submitted to the resource manager 314 where the query service 318 accesses the aggregate demand forecast from the forecasts data store 312.
  • the forecasted ensemble mean is calculated by the disaggregation service 340.
  • the disaggregation service 340 determines the ensemble variance.
  • the sales intensities per store (SIF) is estimated by the disaggregation service 336.
  • the disaggregation service 336 determines the relative sales efficiency of the store or stores at issue compared to all other stores in the retail chain, for a given item.
  • the disaggregated demand forecast is output to the client.
  • the API communicates the demand forecast to the client.
  • the client accesses the forecast through a user interface.
  • the store Sales Intensity Function provides a distribution of the expected values or average sales per unit time amongst all stores selling an item.
  • the Sales Count Distribution (SCD) provides a distribution of the discrete sales counts per unit time across all stores selling an item.
  • the Ensemble Variance Function provides an empirical relation between the ensemble (aggregated over stores) mean and the ensemble variance.
  • the disaggregation methods operate on the assumption that the sales counts are poisson distributed (SPF follows a Poisson distribution) at item-store-day level.
  • the store sales intensity function (SIF) is assumed to be a Gamma distribution and the SCD is assumed to be a Negative Binomial distribution.
  • the store sales intensity function provides a distribution of the expected values or average sales per unit time amongst all stores selling an item.
  • This calculation gives the number of stores per sales intensity interval for a given item.
  • the SIF is used to determine the relative sales performance of each store for an item.
  • the SIF is well-fit by a gamma distribution if a sufficient number of stores are selling the item.
  • SIF shows the spread in sales performance across stores and can be used to compare individual store sales performance to the rest of the retail chain.
  • the discrete aggregated store sales count distribution provides a distribution of the discrete sales counts at a given time across all stores selling an item.
  • the SCD gives the number of stores per sales count number for a given item.
  • the SCD is well-fit by a negative binomial distribution. SCD can be directly measured and fit on historical data, or estimated from aggregate or ensemble parameters.
  • Ensemble Variance Functions provide an empiricial relation between the ensemble (aggregated over stores) mean and the ensemble variance. If direct measurement or forecast of the ensemble variance is nto available, an empirical relation between the ensemble mean and ensemble variance can be used to estimate. The ensemble variance across stores is highly correlated with the ensemble mean and is well-fit by a power-law
  • the simplest disaggregation method is to just equally allocate the sales amongst the stores. This is the equivalent of each store having an instantaneous sales intensity equal to the average chain-level aggregate sales. Equal allocation primarily serves as a good baseline of comparison for other disaggregation methods.
  • a slightly more complex method is to use the fractional contribution of each individual location aggregated over time to provide a simple disaggregation mechanism. This method assumes that the relative contribution of each location is constant over time.
  • the negative binomial distribution can arise from a continuous mixture of Poisson distribution (i.e. a compound probability distribution) where the mixing distribution of the Poisson rate is a gamma distribution.
  • This method assumes that aggregate sales counts across all stores per unit (SCD) is negative binomial distributed, the sales intensities per store (SIF) is gamma distributed, and the sales per unit time for an individual store (SPF) is Poisson distributed. Overall, the assumption is that the relative sales rates between stores for a particular item is stable over time.
  • instantaneous sales intensities for each location can be inferred from a combination of the instantaneous SIF and a known rank-order of each store’s performance. While the SIF cannot be directly measured from the sales counts themselves due to too few counts, the relationship between the aggregate probability distributions can be leveraged to estimate the SIF parameters from the SCD parameters. Further, if the SCD is a negative binomial, then its parameters can be estimated directly from the ensemble mean and ensemble variance. Thus, a chain- level forecast can be disaggregated to the store-level given the forecasts ensemble mean, the ensemble variance, and the relative sales efficiency of each store.
  • Methods and systems of the present disclosure provide advantages over prior systems and methods for predicting item demand in every retail environment.
  • One such advantage is the ability to provide real time updates to demand forecasting models and the demand forecasts that are produced by those models.
  • the models and forecasts are updated as new data is received from the retailer such as new sales data from both retail store locations and web sales.
  • Another advantage of the current system and methods is that the demand forecasts are scalable to accommodate various uses for the demand forecast data. For example, demand forecast data can be used to predict demand for items in a particular retail store on a particular date or demand can be calculated for an entire chain of retail stores for a given month.
  • the system described herein can handle a massive amount of items being offered for sale (e.g. millions).
  • the demand forecasts can also be customized for various levels of granularity depending on the client application requesting the demand forecast and the needs of that client location.
  • the present systems and methods provide a novel approach to solving the problem of accurately predicting demand for particular items within a retail context.
  • the use of weighted component models to generate an ensemble demand forecasting model is novel and advantageous over prior art methods because it allows for flexibility throughout a long time period such as a year, to accommodate changes in demand that occur due to seasonality, holidays, and promotions.
  • the day-to-day accuracy of an ensemble forecasting model is not as important as predicting seasonal demand for items. For example, with school supplies, it is more important to predict general trends in item demand for school supplies for the back-to- school season then it is to accurately predict demand for school supplies items on a day-to-day basis throughout the entire year. This is because, for many retailers, school supplies are sold in the greatest quantities during the“back to school” season, or the months of August and September.
  • the demand forecasting systems and methods of the present disclosure are able to more accurately predict demand for items over the course of a year or a longer time period, taking into account changes in demand for seasonal items. Because so many items within a retail context have changing demand based on seasonality, whether the items are on promotion, or whether the items are relevant to a particular holiday, it is important to be able to take into account seasonal effects.
  • the ensemble model comprising weighted component models is advantageous in that the weighting of the various models can be modified to take into account changes for demand throughout the year based on seasonal effects.
  • the presently disclosed methods and systems go beyond merely predicting how many units of each item customers are likely to buy.
  • the context of retailers having multiple retail store locations and a web based business there are millions of opportunities to make sales to customers.
  • computational methods are required to optimize item offerings to customers and to ensure that items are being stocked both in warehouses and at retail stores that are most likely to be in demand by customers.
  • the present disclosure describes computational methods for analyzing both past sales data and currently occurring sales data to determine which items are going to be in the greatest demand for a given time period and a given location so that an overall retail system can position items and personnel such that customer demand will be met with the proper resources.
  • An example system is for forecasting demand for one or more items in a given time period and location.
  • the system includes an enterprise forecasting engine configured to generate aggregate demand forecasts for all sales of each of a plurality of items within a first time period; a forecast data store configured to store the aggregate demand forecasts; and a server comprising an application programming interface (API) and a disaggregation service stored in memory and executable thereon.
  • API application programming interface
  • the API causes the computing system to: receive and process a client request, the request comprising at least a selection of one or more items and a selection of one or more of a subset of sales or a second time period that is smaller than the first time period, the client requests comprising at least a selection of one or more items, and request and receive an aggregate demand forecast.
  • the disaggregation service causes the computing system to: compute a broken down demand forecast from the aggregate demand forecasts based on the request, and output the broken down demand forecast to the client.
  • the disaggregation service computes the broken down demand forecast by: calculating a forecasted ensemble mean; determining an ensemble variance; estimate sales intensities per store; and determine a relative sales efficiency of a selected store compared to all stores in a retail chain for an item.
  • the aggregate demand forecast is for one week of sales across all stores in a retail chain for one item.
  • the request is for a single day forecast. In some embodiments, the request is for a single store forecast.
  • the server further comprises a CDF service configured to calculate a forecast distribution from an aggregate demand forecast.
  • An example method is for disaggregating an aggregate demand forecast.
  • the method includes: receiving and processing a client request for a demand forecast; requesting and receiving an aggregate demand forecast corresponding to the client request; calculating a forecasted ensemble mean of the aggregate demand forecast; determining an ensemble variance; estimating sales intensities per store based on the ensemble mean and ensemble variance; determining a relative sales efficiency of one or more stores corresponding to the request compared to all stores in a retail chain for an item; and outputting a disaggregated demand forecast to the client.
  • the request includes a time period, a location, and an item.
  • the aggregate demand forecast comprises a forecast over an aggregate time period longer than the time period, and over a plurality of locations.
  • the sales intensities are based, at least in part, on a Sales Intensity Function (SIF) provides a distribution of the expected values or average sales per unit time amongst all stores selling an item.
  • SIF Sales Intensity Function
  • the disaggregated demand forecast is derived at least in part on a fractional contribution of each of a plurality of individual store locations aggregated over time.
  • the method further includes determining an instantaneous sales intensity for at least one store location from among a plurality of locations.
  • determining the instantaneous sales intensity for the at least one store location comprises inferring the instantaneous sales intensity from a combination of an instantaneous value for a Sales Intensity Function (SIF) and a known rank-order of sales performance at least of the plurality of locations.
  • SIF Sales Intensity Function
  • An example non-transitory computer-readable storage medium comprises computer-executable instruction which, when executed by a computing system, cause the computing system to perform a method of generating a demand forecast for one or more items over a selected time period for a selected location.
  • the method includes: receiving and processing a client request for a demand forecast; requesting and receiving an aggregate demand forecast corresponding to the client request; determining a relative sales efficiency of one or more stores corresponding to the request compared to all stores in a retail chain for an item; and outputting a disaggregated demand forecast to the client.
  • the relative sales efficiency is determined by: calculating a forecasted ensemble mean of the aggregate demand forecast; determining an ensemble variance; and estimating sales intensities per store based on the ensemble mean and ensemble variance.
  • the request includes a time period, a location, and an item.
  • the aggregate demand forecast comprises a forecast over an aggregate time period longer than the time period, and over a plurality of locations.
  • the aggregate demand forecast comprises an ensemble forecast generated according to the following equation: where / is a given time, h is a period of time for the forecast, / is an index of features derived from a regression on sales data, is a value for feature j at time /, corresponds to a forecast made at time t from model / for the period t + h, corresponds to a forecast made at time t by the ensemble for period t + h, and correspond to regression coefficients derived from sales data .
  • / is a given time
  • h is a period of time for the forecast
  • / is an index of features derived from a regression on sales data
  • is a value for feature j at time / corresponds to a forecast made at time t from model / for the period t + h
  • the method further includes exposing an API via which the client request is received and the disaggregated demand forecast is output to the client.
  • the request is for a single store forecast on a single day.
  • the system includes a validation tool and a validation server.
  • the validation tool is configured to receive validation sets and selections of configuration options; and send submission packets to a validation server.
  • the validation server is configured to: query a demand forecast data store; store validation sets in a data repository; calibrate a forecasting model with historical training data from a test data repository; test the forecasting model by calculating predictions for each of a plurality of sets of forecast coordinates within the validation sets; save the calculated predictions in the test data repository; calculate forecast validation results; store validation results in a validation data repository; and generate a validation user interface including visualizations of forecast performance.
  • the validation user interface is configured to receive input from an administrator user and display visualizations generated by the validation server.
  • the visualizations comprise one or more of box-plots, Q-Q plots, and histograms.
  • the visualizations are
  • the validation tool comprises a command line tool. In some embodiments, the validation tool is executable on a computing system
  • test data repository comprises a test directory.
  • validation data repository comprises a validation database.
  • Another example method is for validating and visualizing demand forecast models.
  • the method includes: receiving a selection of a demand forecasting model to be validated, a validation set, and configuration options; querying a demand forecast data store to retrieve a demand forecast corresponding to the selections; calibrating the demand forecasting model with historical training data; testing the forecasting model by calculating predictions for each of a plurality of sets of forecast coordinates within the validation set; calculating forecast validation results; and outputting visualizations of performance of the demand forecasting model for the selected configuration options on a validation user interface.
  • the demand forecasting model is an ensemble forecast model built from a combination of component models.
  • the visualizations include one or more of box-plots, histograms, and Q-Q plots.
  • the validation user interface includes a plurality of collapsible graphical sections including: a filter section configured to receive input to upload a validation, receive indications of tags, receive input of a date range, and receive selections at a drop- down list; a sets section configured to display a summary table including
  • the method further includes automatically updating the visualization after changes to the validation sets or metrics are received.
  • the validation set comprises one or more of known data and forecasts.
  • the validation set includes a user, a model, a work stream, and a unique identifier.
  • the validation set comprises a plurality of validation sets.
  • An example graphical user interface is usable to view and analyze results of demand forecast model validations.
  • the graphical user interface includes a plurality of collapsible graphical sections.
  • the collapsible graphical sections include: a filter section configured to receive input to upload a validation, receive indications of tags, receive input of a date range, and receive selections at a drop- down list; a sets section configured to display a summary table including
  • the visualization updates after changes to the validation sets or metrics are received.
  • the update occurs automatically.
  • the graphical user interface is presented within a browser window.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Data Mining & Analysis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne des procédés et des systèmes de prévision de demande pour une pluralité d'articles. En particulier, le système et les procédés de prévision de la demande de la présente invention sont utiles pour prédire la demande de produits dans un contexte de vente au détail. Des modèles de prévision sont construits et utilisés pour affecter un score à des données de ventes entrantes afin de prédire la future demande d'articles. Des modèles de prévision sont validés par évaluation de la demande réelle contre la demande prédite et utilisation de ces informations pour informer sur la manière dont la prévision d'ensemble future sera générée. Des prévisions peuvent être décomposées en composants plus petits pour satisfaire une variété de demandes de données provenant d'applications client.
PCT/US2019/057899 2018-10-26 2019-10-24 Procédé et système de génération de prévisions de demande d'ensemble WO2020086872A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US16/172,575 US11373199B2 (en) 2018-10-26 2018-10-26 Method and system for generating ensemble demand forecasts
US16/172,588 US11295324B2 (en) 2018-10-26 2018-10-26 Method and system for generating disaggregated demand forecasts from ensemble demand forecasts
US16/172,603 US11170391B2 (en) 2018-10-26 2018-10-26 Method and system for validating ensemble demand forecasts
US16/172,575 2018-10-26
US16/172,588 2018-10-26
US16/172,603 2018-10-26

Publications (1)

Publication Number Publication Date
WO2020086872A1 true WO2020086872A1 (fr) 2020-04-30

Family

ID=68536913

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/057899 WO2020086872A1 (fr) 2018-10-26 2019-10-24 Procédé et système de génération de prévisions de demande d'ensemble

Country Status (1)

Country Link
WO (1) WO2020086872A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114693182A (zh) * 2022-05-30 2022-07-01 国网浙江省电力有限公司杭州供电公司 基于云融合技术的业务工单化的数据处理方法
US20230037228A1 (en) * 2021-07-13 2023-02-02 Tata Consultancy Services Limited Systems and methods for application-aware dynamic slicing in radio access network (ran)
CN116151861A (zh) * 2023-04-21 2023-05-23 杭州比智科技有限公司 基于间断时间序列样本构建的销量预测模型及构建方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150134413A1 (en) * 2013-10-31 2015-05-14 International Business Machines Corporation Forecasting for retail customers
WO2016073025A1 (fr) * 2014-11-04 2016-05-12 Hewlett Packard Enterprise Development Lp Prévision et simulation de la demande

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150134413A1 (en) * 2013-10-31 2015-05-14 International Business Machines Corporation Forecasting for retail customers
WO2016073025A1 (fr) * 2014-11-04 2016-05-12 Hewlett Packard Enterprise Development Lp Prévision et simulation de la demande

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230037228A1 (en) * 2021-07-13 2023-02-02 Tata Consultancy Services Limited Systems and methods for application-aware dynamic slicing in radio access network (ran)
US12101637B2 (en) * 2021-07-13 2024-09-24 Tata Consultancy Services Limited Systems and methods for application-aware dynamic slicing in radio access network (RAN)
CN114693182A (zh) * 2022-05-30 2022-07-01 国网浙江省电力有限公司杭州供电公司 基于云融合技术的业务工单化的数据处理方法
CN114693182B (zh) * 2022-05-30 2022-08-26 国网浙江省电力有限公司杭州供电公司 基于云融合技术的业务工单化的数据处理方法
CN116151861A (zh) * 2023-04-21 2023-05-23 杭州比智科技有限公司 基于间断时间序列样本构建的销量预测模型及构建方法

Similar Documents

Publication Publication Date Title
US12002063B2 (en) Method and system for generating ensemble demand forecasts
US11170391B2 (en) Method and system for validating ensemble demand forecasts
US11295324B2 (en) Method and system for generating disaggregated demand forecasts from ensemble demand forecasts
US10592811B1 (en) Analytics scripting systems and methods
US8738425B1 (en) Apparatus, system and method for processing, analyzing or displaying data related to performance metrics
US8370191B2 (en) Method and system for generating quantitative indicators
JP5247434B2 (ja) リスクの評価及び提示のためのシステム及び方法
US20200372529A1 (en) System and method for selecting promotional products for retail
US20150347921A1 (en) Trust Rating Metric for Future Event Prediction of an Outcome
KR102319193B1 (ko) 광고 마케팅 업무 관리 방법 및 시스템
US20130151423A1 (en) Valuation of data
JP2004519021A (ja) 動的値付けシステム
US20150254791A1 (en) Quality control calculator for document review
US11887138B2 (en) System and method for retail price optimization
CN106796527A (zh) 基于价格和性能优化云服务的选择的系统和方法
WO2016155514A1 (fr) Procédé et dispositif de programmation de services de logistique
US9230211B1 (en) Analytics scripting systems and methods
US20210224833A1 (en) Seasonality Prediction Model
US11823238B1 (en) Virality cause determination
US20120290543A1 (en) Accounting for process data quality in process analysis
US20080082386A1 (en) Systems and methods for customer segmentation
WO2020086872A1 (fr) Procédé et système de génération de prévisions de demande d'ensemble
US11403652B1 (en) Customer-level lifetime value
US7783547B1 (en) System and method for determining hedge strategy stock market forecasts
US20130090987A1 (en) Methods and system for workflow management of sales opportunities

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19802014

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19802014

Country of ref document: EP

Kind code of ref document: A1