The present subject matter relates generally to computing systems for retail or demand
forecasting. More particularly, but not exclusively discloses a system and a method for
forecasting demand of a plurality of products for a retail organization using artificial
intelligence and machine learning based techniques.
BACKGROUND
[02] Typically, products and services of one or more organizations are delivered to
consumers through a network of manufacturers, distributors, transporters, retailers, etc.
Such a network of facilities that together deliver products to consumers is commonly
referred to as a “supply chain” network. Suppliers of products (e.g., manufactures,
vendors, retailers, etc.) often face the task of forecasting demand for the products in
order to provide a smooth and efficient flow of the products through the supply chain
network in the presence of constantly changing market conditions. Under-estimating or
overestimating the demand can result in underproduction or overproduction and
increased costs associated with holding inventories (e.g., storage costs, obsolescence,
etc.). Underestimating the demand, on the other hand, can result in lost revenues.
[03] Further, in the retail industry, retailers need to predict their demand in the future to
better manage their inventory or promotion/markdown planning. Retailers may engage
in many types of promotion to boost their sales. To generate an accurate forecast, a
retailer has to consider all factors/features which could impact the demand, such as
promotions, price, seasonality, weather, etc.
[04] Currently, there are various solutions existing in determining retail forecasts. However,
the existing solutions suffer from one or more drawbacks such as high reliance on
human input or statistical data based mathematical forecast methods. In either of these
existing solutions, are less accurate, error prone, capable of processing static or
historical data, not completely automated and consideration of irrelevant or
inappropriate set of parameters for forecast.
SUMMARY
[05] One or more shortcomings of the prior art may be overcome, and additional advantages
may be provided through the present disclosure. Additional features and advantages
may be realized through the techniques of the present disclosure. Other embodiments
3
and aspects of the disclosure are described in detail herein and are considered a part of
the claimed disclosure.
[06] Disclosed herein is a system for forecasting demand for a retail organization. The
system includes a hardware processor; and a memory coupled to the processor. The
memory includes a set of program instructions in the form of a plurality of subsystems,
configured to be executed by the processor. The plurality of subsystems includes a sales
data gathering subsystem configured to obtain real time sales input datasets associated
with one or more products from one or more data sources via a network. The real time
sales input datasets comprises categories of sales information classified as product
identification data category, sale performance data category, sales transactional data
category, sales resource data category, sales period data category and revenue level data
category. Further, the plurality of subsystems further includes a sales data preprocessing
subsystem configured to preprocess the real time sales input datasets associated with
one or more products. Furthermore, the plurality of subsystems includes a sales data
feature generation subsystem configured to generate sales data features associated with
the preprocessed real time sales input datasets by analyzing a sales data trend of each
of the preprocessed real time sales input datasets. The sales data features includes sales
validation data features and sales test data features. Furthermore, the plurality of
subsystems includes sales data validation model training subsystem configured to
generate a machine learning model for validation datasets based on the generated sales
data features. The machine learning model for validation datasets represents a
correlation between the sales validation data features, sales validation forecast data set,
and sales validation actual sales data set as dependent variable. Additionally, the
plurality of subsystems includes a sales data testing model training subsystem
configured to generate a machine learning model for sales test data based on the
generated sales data features. The machine learning model for sales test data represents
a correlation between the sales test data features and sales test forecast data set.
Moreover, the plurality of subsystems includes sales forecast prediction subsystem
configured to predict a sales forecast value for a defined time period based on the
generated machine learning model for sales test data set and validation data set.
[07] Further, the present disclosure includes a method for forecasting demand for a retail
organization. The method includes obtaining real time sales input datasets associated
with one or more products from one or more data sources via a network. The real time
sales input datasets comprise categories of sales information classified as product
4
identification data category, sale performance data category, sales transactional data
category, sales resource data category, sales period data category and revenue level data
category. Further, the method includes pre-processing the real time sales input datasets
associated with one or more products. The method further includes generating sales
data features associated with the pre-processed real time sales input datasets by
analysing a sales data trend of each of the pre-processed real time sales input datasets.
The sales data features comprise sales validation data features and sales test data
features. Further, the method includes generating a machine learning model for
validation datasets based on the generated sales data features. The machine learning
model for validation datasets represents a correlation between the sales validation data
features, sales validation forecast data set, and sales validation data set actual sales as
dependent variable. Additionally, the method includes generating a machine learning
model for sales test data set based on the generated sales data features. The machine
learning model for sales test data set represents a correlation between the sales test data
features and sales test forecast data set. Moreover, the method includes forecasting a
sales value for a defined time period based on the generated machine learning model
for validation and testing data set. Also, the method includes outputting the forecasted
sales value on a user interface of a computing device.
[08] The foregoing summary is illustrative only and is not intended to be in any way limiting.
In addition to the illustrative aspects, embodiments, and features described above,
further aspects, embodiments, and features will become apparent by reference to the
drawings and the following detailed description.
BRIEF DESCRIPTION OF THE ACCOMPANYING DIAGRAMS
[09] The accompanying drawings, which are incorporated in and constitute a part of this
disclosure, illustrate exemplary embodiments and, together with the description, serve
to explain the disclosed principles. In the figures, the left-most digit(s) of a reference
number identifies the figure in which the reference number first appears. The same
numbers are used throughout the figures to reference like features and components.
Some embodiments of system and/or methods in accordance with embodiments of the
present subject matter are now described, by way of example only, and with reference
to the accompanying figures, in which:
5
[010] FIG 1 is a block diagram of a computing system capable of forecasting demand for a
retail organization, according to an embodiment of the present invention;
[011] FIG 2 is an exemplary block diagram depicting a process of generating a machine
learning model for the validation data set, according to an embodiment of the present
invention;
[012] FIG 3 is an exemplary block diagram depicting a process of generating a machine
learning model for the test dataset, according to an embodiment of the present
invention;
[013] FIG 4 is an exemplary block diagram depicting a process of forecasting sales value for
a defined time period, according to an embodiment of the present invention;
[014] FIG 5 is a process flowchart illustrating an exemplary method of forecasting demand
for a retail organization, according to an embodiment of the present invention; and
[015] FIG 6A-E is a graphical representation of one or more exemplary sales forecast trends,
according to an embodiment of the present invention.
[016] It should be appreciated by those skilled in the art that any block diagrams herein
represent conceptual views of illustrative systems embodying the principles of the
present subject matter. Similarly, it will be appreciated that any flow charts, flow
diagrams, state transition diagrams, pseudo code, and the like represent various
processes which may be substantially represented in computer readable medium and
executed by a computer or processor, whether or not such computer or processor is
explicitly shown.
DETAILED DESCRIPTION
[017] In the present document, the word "exemplary" is used herein to mean "serving as an
example, instance, or illustration." Any embodiment or implementation of the present
subject matter described herein as "exemplary" is not necessarily to be construed as
preferred or advantageous over other embodiments.
[018] While the disclosure is susceptible to various modifications and alternative forms,
specific embodiment thereof has been shown by way of example in the drawings and
will be described in detail below. It should be understood, however that it is not
intended to limit the disclosure to the forms disclosed, but on the contrary, the
disclosure is to cover all modifications, equivalents, and alternative falling within the
scope of the disclosure.
6
[019] The terms “comprises”, “comprising”, “includes” or any other variations thereof, are
intended to cover a non-exclusive inclusion, such that a setup, device or method that
includes a list of components or steps does not include only those components or steps
but may include other components or steps not expressly listed or inherent to such setup
or device or method. In other words, one or more elements in a system or apparatus
proceeded by “comprises… a” does not, without more constraints, preclude the
existence of other elements or additional elements in the system or method.
[020] Throughout the specification, the terms “subsystem” and “module” are used
interchangeably.
[021] The present invention provides a system for forecasting retail sales accurately. The
system is configured to take data input (attributes) associated with the product such as
sales, daily stock info, SKU (stock keeping unit), customer details, colour, time, price
etc. The system then aggregates and cleans the acquired data to bring data into desired
format. The system is then configured to apply basic analysis on the arranged data.
After analysis, feature engineering is performed to determine patterns associated within
the data. The system consists of a forecasting module configured to forecast sales based
on insights from analysis patterns predicted by feature engineering. The system then
utilizes ensemble modelling strategy to perform core modelling which reduces model
variance by combining output from various base models and determine sales forecast.
[022] Referring now to the drawings, and more particularly to FIG. 1 through 6A-E, where
similar reference characters denote corresponding features consistently throughout the
figures, there are shown preferred embodiments and these embodiments are described
in the context of the following exemplary system and/or method.
[023] FIG 1 is a block diagram of a computing system 100 capable of forecasting demand
for a retail organization, according to an embodiment of the present invention.
According to FIG. 1, the computing system 100 includes a processor 102, a memory
106, and a bus 104. The memory 106 includes a plurality of subsystem which further
includes a sales data gathering module 108, a sales data preprocessing module 110, a
sales data feature generation module 112, sales data validation model training module
114, sales data testing model training module 116 and sales forecast prediction module
118. The processor 102, and the memory 106, may be communicatively coupled by a
system bus such as a system bus 104 or a similar mechanism.
7
[024] The processor 102 may be configured to implement functionality and/or process
instructions for execution within the computing system 100. The processor 102 may be
capable of processing instructions stored in the memory 106. The processor 102 may
include any one or more of a processors, a controller, a digital signal processor (DSP),
an application specific integrated circuit (ASIC), a field-programmable gate array
(FPGA), or equivalent discrete or integrated logic circuitry. Additionally, the functions
attributed to the processor 102, in this disclosure, may be embodied as software,
firmware, hardware or any combination thereof. The processor 102 as used herein,
means any type of computational circuit, such as, but not limited to, a microprocessor,
a microcontroller, a complex instruction set computing microprocessor, a reduced
instruction set computing microprocessor, a very long instruction word microprocessor,
an explicitly parallel instruction computing microprocessor, or any other type of
processing circuit. The processor 102 may also include embedded controllers, such as
generic or programmable logic devices or arrays, application specific integrated
circuits, single-chip computers, smart cards, and the like.
[025] The memory 106 may be configured to store sales related information during the
operation. The memory 106 may, in some examples, be described as a computerreadable storage medium. The memory 106 may be described as a volatile memory,
meaning that the memory does not maintain stored contents when the computer is
turned off. Examples of volatile memories include random access memories (RAM),
dynamic random-access memories (DRAM), static random-access memories (SRAM),
and other forms of volatile memories known in the art. In some examples, the memory
106 may be used to store program instructions for execution by processor 106.
Specifically, the memory 106 includes a set of program instructions in the form of a
plurality of subsystems, configured to be executed by the processor 102. For example,
the plurality of subsystems includes a sales data gathering module 108, a sales data
preprocessing module 110, a sales data feature generation module 112, sales data
validation model training module 114, sales data testing model training module 116 and
sales forecast prediction module 118 stored in the form of program instructions for
execution by the processor 102. The plurality of subsystems can be implemented as
software, hardware, or some combination of software and hardware. For example, the
plurality of subsystems could be implemented as a part of an application specific
integrated circuit (ASIC). The plurality of subsystems includes routines, programs,
8
objects, components, data structures, etc., which perform particular tasks or implement
particular abstract data types.
[026] According to an embodiment described herein, the sales data gathering subsystem 108
is configured to obtain real time sales input datasets associated with one or more
products from one or more data sources via a network. The real time sales input datasets
include categories of sales information classified as product identification data
category, sale performance data category, sales transactional data category, sales
resource data category, sales period data category and revenue level data category. The
product identification information includes product size, colour, and other sku attributes
associated with the product. The sale performance data category includes location of
sale, time period, and so on. The sales transactional data category comprises product
manufactured, product sold, products not sold and the like. The revenue level data
category includes profits and loss computed with respect to products produced and the
time period.
[027] The sales data preprocessing subsystem 110 is configured to preprocess the real time
sales input datasets associated with one or more products. Specifically, the sales data
preprocessing subsystem 110 is configured to analyze the real time sales input datasets
associated with the one or more products. Further, the sales data preprocessing system
110 is configured to extract relevant sales input datasets from the analyzed real time
sales input datasets based on one or more predefined rules. The one or more predefined
rules comprises data content check, checking for negative sales, checking if invalid
datasets is present, removal of duplicates, removal or correction of outliers, presence of
bulk order sales and its correction and the like. Further, the sales data preprocessing
system 110 is configured to normalize the extracted relevant sales input datasets using
a relevant sales data scaling technique. Additionally, the sales data preprocessing
system 110 is configured to classify the normalized sales input datasets into trained
sales validation datasets and sales test datasets based on the time period required for the
validation and test set. The classified sales input datasets are inputted to the sales data
feature generation subsystem 112. The entire process of preprocessing is further
disclosed below under the ‘data preparation’ stage.
[028] The sales data feature generation subsystem 112 is configured to generate sales data
features associated with the preprocessed real time sales input datasets by analyzing a
sales data trend of each of the preprocessed real time sales input datasets, wherein the
sales data features comprises sales validation data features and sales test data features.
9
The sales data features are characterized attributes of the sales data, for example,
‘lagged version’ or holiday features or the like. Specifically, the sales data feature
generation subsystem 112 is configured to detect a sales data pattern for each of the
preprocessed real time sales input datasets using one or more pattern analysis rules. The
one or more pattern analysis rules has been explained in detailed below under the
‘feature engineering’ stage. Further, the sales data feature generation subsystem 112 is
configured to determine one or more sales data attributes corresponding to the detected
sales data pattern by correlating the detected sales data pattern with the real time sales
input datasets. The one or more sales data attributes includes date, store, sku, invoice
quantity and the like. Also, the sales data feature generation subsystem 112 is
configured to generate sales data features associated with the preprocessed real time
sales input data set based on the determined one or more sales data attributes.
[029] The sales data validation model training subsystem 114 is configured to generate a
machine learning model for the validation data set based on the generated sales data
features. The machine learning model for the validation data set represents a correlation
between the sales validation data features, sales validation forecast data set, and sales
validation actual sales data as dependent variable. The machine learning model for
validation data set may be a linear regression, neural network or Gradient boosting -
tree based model. Specifically, the sales data validation model training subsystem 114
is configured to determine a correlation between the sales validation data features and
the trained sales validation datasets using a base machine learning model. The base
model training and overview has been explained further in FIG 2. Further, the sales
data validation model training subsystem 114 is configured to generate the sales
validation forecast data set based on the determined correlation between the sales
validation data features and the trained sales validation datasets. Also, the sales data
validation model training subsystem 114 is configured to generate the machine learning
model for the validation data set based on the generated sales validation data set. The
machine learning model represents the correlation between the sales validation data
features, the trained sales validation datasets, the sales validation forecast data set from
each base model, and the sales validation actual sales data set as dependent variable.
[030] Subsequently, the sales data testing model training subsystem 116 is configured to
generate a machine learning model for sales test set based on the generated sales data
features. The machine learning model for sales test set represents a correlation between
the sales test data features and sales test forecast data set. The machine learning model
10
for the sales test set may be a linear regression, neural network or Gradient Boosting -
tree based model. Specifically, the sales data testing model training subsystem 116 is
configured to determine a correlation between the sales test data features and the sales
test datasets combined with the corresponding sales validation data features using a
base machine learning model. Further, the sales data testing model training subsystem
116 is configured to generate the sales test forecast data set based on the determined
correlation. Also, the sales data testing model training subsystem 116 is configured to
train the machine learning model for sales test set based on the generated sales test
forecast data set. The machine learning model for sales test set represents the correlation
between the sales test data features, and the sales test forecast data set from each base
model.
[031] The sales forecast prediction subsystem 118 is configured to predict a sales forecast
value for a defined time period based on the generated machine learning model for test
and validation datasets. The defined time period may be daily basis, weekly basis,
monthly basis, or yearly basis. Specifically, in order to predict the sales forecast value,
the sales forecast prediction subsystem 118 is configured to train a meta model using
the sales validation forecast data set, the sales validation data features, and the sales
validation data set actual sales as a dependent variable derived from the machine
learning model for validation datasets. Further, the sales forecast prediction subsystem
118 is configured to determine a correlation between the trained meta model datasets
and the sales test data features, the sales test forecast data set derived from the machine
learning model for sales test data set. Furthermore, the sales forecast prediction
subsystem 118 is configured to predict the sales forecast value for the defined time
period based on the determined correlation.
[032] In operation, the entire process of forecasting demand for a retail organization may be
divided into data preparation stage, data analysis stage, feature engineering stage,
model training stage, and finally the prediction stage. Each of these stages are
performed by the above-mentioned plurality of subsystems accordingly.
[033] In the data preparation stage, primarily handled by the sales data gathering subsystem
108, real time sales input datasets are gathered from various external or internal data
sources. These data sources may be storage systems capable of storing such categories
of sales data. Further, the gathered real time sales input datasets are converted into a
predefined format. Furthermore, the gathered real time sales input datasets are filtered
to remove unnecessary and noisy data, such as for example, but not limited to, special
11
characters #, *, and so on. Further, the gathered real time sales input datasets are further
filtered based on use case, removal of unnecessary columns, checking for negative
sales, checking if invalid datasets present in dataset (like integer values in date column,
string values in integer column, invalid dates, and the like), presence of bulk order sales,
and correcting it, removal of duplicates, removal or correction of outlier’s datasets and
the like. The filtration methods include identification of bulk sales based on domain
insights and replacing them with zero sales. The correction of outliers is performed
using inter quartile range (IQR) analysis. The sales values higher than upper bound
sales values obtained from IQR analysis, are capped to this upper bound. Alternatively,
a distribution plot analysis may also be used to detect the outliers in the real time sales
input data. In this method, a smoother version of sales frequency plot is derived
(smoothed histogram of sales). Generally, values located in the long-tailed side of
distribution are searched. Sales higher than this upper bound are considered as outliers.
Further, missing sales values in the obtained real time sales input data is filled. The
sales transactional data consists of observations for sales based on time, store and sku
combination. At specific times, if sales do not happen, those no sales entries are not
present in the dataset. In such cases, factors such as why sales did not happen, may be
no demand, may be no stock at stores, may be stock is expired (for perishable items)
are determined. Imputing sales (for EDA phase requirement) is the next stage in data
preparation. This is a three-step process. First, missing sales values are filled with zero
sales and then incremental models are trained to forecast sales for the training period.
Second, forecasted sales value and daily stock information are used for detecting stock
outs. Third, for detected stock outs instances, missing sales values are filled with
forecasted sales and for rest of the instances are filled with zero sales. Generally, data
preparation methods such as, but not limited to, integer encoding, one hot encoding are
performed.
[034] The next stage is the data analysis stage. Once the data is prepared, it is used for data
analysis by a sales data preprocessing subsystem. In this stage, an Exploratory Data
Analysis (EDA) is used. The EDA analysis is crucial in the solution of any typical data
science use cases. This process starts with the steps of understanding the meaning of
attributes present in the real time sales input data. The process proceeds with simple
analytical questions and gradually dives deeper into data to unfold hidden patterns and
insights to form critical business decisions. This process amounts to analyzing the real
time sales input datasets associated with the one or more products. In the retail industry,
12
the EDA identifies critical gaps in supply chain planning and inventory planning. The
complete EDA process is executed in various phases, namely, basic analysis,
understanding factors which impact sales, and lost sales and excess inventory costs
analysis. In the basic analysis phase, different data attributes are first analyzed. In some
cases, opinions from domain experts to understand the meaning of attributes are
inputted. Next, top selling stores, skus, month (by quantity and revenue) are analyzed.
In this case, a total sale (either by quantity or revenue) for each store or for each skus
or for every month are computed. Then, total sales computed for each category
mentioned above is sorted to create a bar plot. This helps in understanding the most
important drivers of sales (to focus). Also, in this case, this analysis may be extended
by plotting most expensive products and its sales contribution. Next, zero sales analysis
is performed. To conduct this analysis, missing sales values are filled with zeros only
(instead of imputing based on forecasts). Further, the percentage of zero sales is
computed to understand zero sales volume. To extend it further, a few store-sku
combinations are selected and a plot is filled with sales on Y axis and Time on X axis.
By looking at such a plot, intermittency in data is confirmed. The intermittent sales
means observance of sudden occurrence of zero sales during its sales history. This
makes it difficult to forecast and makes the sales data noisy. Next, Product launch and
discontinuation analysis is performed. Given two to three years of sales history, some
products launched two years ago and discontinued one year ago are analyzed. Likewise,
for all products, there is a specific launch date and a discontinued date. The launch date
means first observation of sales of respective products. The discontinued date means
last observation of sales of respective products. The products which are still in active
phase of sale, those have the latest date of sales observation as its last observation.
Finally, revenue breakdown by month, stores, and category is performed. This analysis
is very similar to top selling analysis. In this case, instead a pie plot is created to
understand the percentage contribution of top performing month, store and category.
This analysis can be thought of as another side of top selling analysis that was described
earlier in this section with extension.
[035] In the next phase of EDA, which is the understanding factors which impact sales, trend
analysis is performed. In the retail sector, based on type of products and location, some
products witness an increasing trend (upward trend, i.e., moving average of sales is
increasing over time), while some products witness downward trend. To accurately
13
forecast future sales, trends are the most important property to investigate. Some of the
trend analysis are depicted in FIG 6A-6E.
[036] The last phase of EDA, which is lost sales and excess inventory costs analysis is
performed. This phase amounts to extract relevant sales input datasets from the
analyzed real time sales input datasets and normalize the extracted relevant sales input
datasets using a relevant sales data scaling technique. The EDA revolves around two
important dimensions of retails sales analysis, namely, lost sales and excess inventory
costs. The lost sales in retail is referred to as when a customer lands in a store and is
unable to find what he needs; this means the company lost sales. When this happens
across stores and items, and if more often, this lost sale accumulates to millions of
dollars. This makes this problem worth solving. However, before this problem is
solved, the potential of impact on revenue and costs is to be identified and estimated.
The excess inventory costs is referred as when the shelf is occupied with products with
less demand, the store loses the opportunity to sell products with more demand. In such
cases, stores incur costs due to excess inventory. Sometimes, perishable goods become
waste if unable to sell due to excess inventory. Such costs are also included in excess
inventory costs. With these two dimensions given, lost sales are identified using a
predefined approach. In this approach, provided that daily sales, daily inventory and
weekly forecasts information are available, lost sales calculation is carried out. Lost
sales calculations happen at various frequencies e.g., weekly, fortnightly or monthly.
Below is the step-by-step approach to quantify lost sales. In the first step stock out
detection is performed by
[037] a. calculating stock out days for each week (i.e., days where stock is zero); and
[038] b. Consider all weeks where stock out days number is non-zero.
[039] In the second step, a lost sales formula is applied where for each considered week, if
week forecast is greater than week sales, then lost sales value is equal to (week forecast
minus week sales) multiplied with selling price of respective products. In the third step,
sum all lost sales for a given week is determined to understand organization wide loss
in sales.
[040] Further, the other dimension, excess inventory costs is calculated using another
predefined approach in which calculation happens every week. At the end of each week,
parameters such as sales taken place, required safety cover and stock in hand are known.
If the stock in hand is greater than required safety cover minus Sales, then excess
inventory cost is determined as
14
(Stock in hand - (required safety cover - Sales)) * Selling price.
[041] Else, it implies that there is no excess inventory cost. The excess inventory calculations
happen at various frequencies e.g., weekly, fortnightly or monthly.
[042] Furthermore, in this stage, the real time sales input data is normalized. However, the
scaling is not applied on target variable i.e., actual sales, which means there is no back
transformation required on generated forecasts. The scaling generally helps to bring all
numerical variables to stay within common scale or range. Different variables represent
different things in different scales, for example, quantity, revenue, ranks, holiday
distance and so on. Scaling them all in known range or scale, brings consistency in data
for the model training phase to be robust. Otherwise, scaling issues create confusion or
inconsistency for model training algorithms.
[043] Following are the various normalization techniques that may be considered: a. Standard
scaler; b. Quantile scaler; c. Robust scaler; d. Min-max scaler; e. None scaler (no
scaling at all). Each model, described herein, are trained using a prepared dataset using
each scaler, and record results separately. At the end of experimentation, the most
efficient scaler to be deployed is determined.
[044] At the end of the EDA stage, the normalized data is classified into trained sales
validation datasets and sales test datasets based on the type and content of the sales
input datasets.
[045] The next stage is the feature engineering stage. This stage is performed by a sales data
feature generation subsystem. This stage generates sales data features associated with
the preprocessed real time sales input datasets by analyzing the sales data trend of each
of the preprocessed real time sales input datasets, where the sales data features includes
sales validation data features and sales test data features. The feature engineering stage
is the most critical phase to ensure high quality of forecasts. Feature engineering is the
scientific process of creating dataset attributes which explains sales patterns. If there is
a specific pattern present in sales data, this needs to be explicitly identified and
respective features are created based on that, to ensure visibility of such patterns to the
model training stage. Below are the exemplary sales data features generated: a. features
for seasonality; b. features for trends; c. features for holiday; d. features for items and
store ranks by volume of revenue; e. features for time. The first type is seasonality
features. Most statistical models are capable of handling single seasonality (single time
series at a time). To handle multiple seasonality, statistical models become
computationally expensive. In the EDA phase, dominant seasonalities present in most
15
time series in the dataset are identified. This amounts to detection of a sales data pattern
for each of the preprocessed real time sales input datasets using one or more pattern
analysis rules. Then to add these seasonalities in form of features, lagged versions of
sales at different windows (based on identified seasonalities) are created. This lagged
version is one type of sales data feature. For example, a weekly season for daily
frequency is created using seventh lagged sales against each sales present in data (store
- sku level) (window size is seven here). In this case, sample data are used to
demonstrate creation of lagged features.
[046] Input data for daily frequency is shown in below Table. 1:
Date Store Sku Invoice qty
d1 a b 2
d2 a b 5
d3 a b 1
d4 a b 6
d5 a b 2
d6 a b 4
d7 a b 10
d8 a b 1
d9 a b 4
d10 a b 1
d11 a b 3
d12 a b 6
d13 a b 6
d14 a b 13
Table. 1
[047] To create a lagged version of the sale feature with window size of seven i.e., to
incorporate weekly seasonality in form of feature, below steps are performed.
[048] First, the sales sequence is completed by seven places and add this shifted series in the
dataset. This operation is performed for each store-sku combination. This amounts to
determining one or more sales data attributes (in this case the sales sequence, date store,
sku, invoice quantity, as given in below Table. 2) corresponding to the detected sales
16
data pattern by correlating the detected sales data pattern with the real time sales input
datasets. After performing this on a sample dataset, below output is obtained.
Date Store Sku Invoice qty Sale_lag_7
d
1
a b 2 NaN
d
2
a b 5 NaN
d
3
a b 1 NaN
d
4
a b 6 NaN
d
5
a b 2 NaN
d
6
a b 4 NaN
d
7
a b 10 NaN
d
8
a b 1 2
d
9
a b 4 5
d
10
a b 1 1
d
11
a b 3 6
d
12
a b 6 2
17
d
13
a b 6 4
d
14
a b 13 10
Table. 2
[049] In this way, lagged versions of sales are formed and added in data. This feature
enhances the predictive power of the model because it possesses good correlation with
actual sales. Depending on the seasonality analysis, the most dominant seasons in the
sales pattern are identified and such sales data features are generated. This lagged
version is one such example of generated sales data feature. Note that NaNs in data are
converted to zeros without much impact on the model for smaller size of the season
window.
[050] In case of a holiday sales data feature, which are usually of binary nature and separate
for a given holiday. This results in categorical features, and as the number of holidays
increases, the dataset becomes more sparse.
[051] To solve this problem and improve the performance of holiday features, those features
are converted into numerical nature by computing the average distance to holiday from
any given day. This amounts to determining one or more sales data attributes
corresponding to the detected sales data pattern by correlating the detected sales data
pattern with the real time sales input datasets. In this way, features convey more useful
information to model, instead of binary yes and no. To understand why such numerical
features are able to express more information instead of binary variables, a small
representative example is taken. For example, holiday is observed on 25th December
in last year's sales history. If the sales history is observed more closely, it may be
discovered that, most of the time, holiday influence on sales starts before the actual
holiday comes. And sometimes stay after holiday as well. To model /express this effect,
numerical holiday features outperforms binary holiday features. There are generally
two variations of binary variables explained below with comparison to numerical
versions. In the first variation, that is flag holiday sales observation only. In this case,
a “1” value is assigned on the 25th December sales observation’s holiday column
(binary). Further, a value “0” is assigned everywhere else. On the other hand, a
numerical holiday column shall have a value “0” as it represents distance to the holiday
date. In this case, numerical values start to decrease as the holiday date approaches and
18
increase post-holiday. This clearly correlates with the influenced sale pattern around
holiday. In this case, the binary feature fails to explain the influence of sales before and
after the holiday. This binary feature is one example of the generated sales data feature.
[052] In the second variation, which is Flag selected dates around a given holiday. In this
case, a “1” value is assigned on some dates before the actual holiday date and some
dates after the actual holiday. A value “0” is assigned everywhere else. The numerical
version behaves the same way as described in the first variation. In this case, the binary
feature tries to address the before and after holiday effect, however, technically as it
assigned the same value “1”, it explains all marked days as holiday, instead of before
or after effect. The numerical version, which is based on distance metric, clearly
expresses more than its binary counterpart.
[053] Additionally, in case of ranking based features, ranks are assigned to stores, skus, storesku combinations, category and so on based on observed revenue at respective levels.
This ranking then helps to model sales based on the importance of particular sku or
store or combination or category.
[054] The next stage is the model training stage. The model training and model generation is
performed by sales data validation model training subsystem 114 and sales data testing
model training subsystem 116. Modelling helps to forecast future sales based on the
EDA insights and feature engineering effort. In this case, an overview of ensemble
models is disclosed. In this stage, models such as base models are trained and are used
to generate validation model and test models and predict the sales forecast value using
model ensemble strategy. There are various types of model ensemble strategy such as
but not limited to, averaging, stacking and blending and so on. In an embodiment, any
ensemble strategy consists of base models and a unique approach to combine output of
those base models. Ensemble approach helps in reducing model variance by using a set
of uncorrelated base models and combining them to increase the expressive power of
the model and ultimately improve the overall performance of the model.
[055] In the averaging method, a simple or weighted average of base models forecasts are
taken. This forecast is the sales validation or sales test forecast. In the stacking method,
a meta model is specified to combine the base model’s forecasts, which is for example,
the sales validation forecast and sales test forecast. In this case, training of base and
meta model, both takes place sequentially. The meta model takes forecasts of base
model as training input data as primary independent variables and corresponding target
19
variable as dependent variable. This approach considers forecasts for all given training
examples as input to the meta model.
[056] Blending method is almost similar to the stacking method. Key difference is that
blending considers holdout set to train meta model unlike stacking (which considers
forecasts for all training examples). In this case, the nature of datasets is time dependent
and continuity is essential. Hence, blending strategy is more suitable in a time series
forecasting use case (instead of stacking).
[057] In an embodiment, a data split strategy may be used for ensemble models. In this case,
each dataset X, which are the independent features are further classified into sub-dataset
Y, which are the dependent variables-sales. Each of the dataset X and its corresponding
sub-dataset Y are trained with historical sales data. Further, each of the dataset X and
its corresponding sub-dataset Y are used to generate respective sales data features as
described herein. Furthermore, each of the dataset X is used to generate test dataset X
on the fly or at the real time and its corresponding sub-dataset Y is further used to
forecast future sales. The datasets X and sub datasets Y are classified as train and
validation sets to generate forecasts for validation and test, respectively.
[058] In the last stage, which is the prediction stage, the trained models are ensembled using
an appropriate ensemble strategy to predict the sales forecast value.
[059] The functionalities of the bus 104 are well known to a person skilled in the art and
hence the explanation thereof is omitted.
[060] The interface(s) (not shown in FIG) may include a variety of software and hardware
interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse,
an external memory, and a printer. The interface(s) can facilitate multiple
communications within a wide variety of networks and protocol types, including wired
networks, for example, local area network (LAN), cable, etc., and wireless networks,
such as Wireless LAN (WLAN), cellular, or satellite.
[061] FIG 2 is an exemplary block diagram 200 depicting a process of generating a machine
learning model for validation datasets, according to an embodiment of the present
invention. In FIG 2, a stack of trained sales datasets 202 comprising trained sales
datasets 210A-210N, identified to be relevant, are retrieved from a database. The
retrieved trained sales datasets 210A-N are then fed to a base model 204 for training.
In an exemplary embodiment, the base models 204 may be a Linear regression model,
or a neural network or a light gradient boosted tree. The base models 204 are typical
regression models to forecast future sales for given store-sku combinations. This
20
training of base model 204 is an experimental exercise which consists of building stable
cross validation design and determining best performing hyperparameters. The crossvalidation framework is constant across base models 204. Using the same design,
hyperparameter tuning is carried out to determine the best set of parameters. There are
various methods by which cross validation design and hyperparameter tuning is
performed. Firstly, a light GBM model cross validation design is used. In this case,
three cross validation sets are created based on expanding window strategy. In each set,
a gap of predefined horizon is maintained. For example, a four-week horizon for weekly
data may be used. Further, the four week’s data between train and validation set (5th
week after train’s last week) are skipped in each set. The base model 204 is then trained
on each set and performance is being recorded for the validation set. Based on the
obtained performance, model tuning activity is carried out. To accelerate model tuning
a random search algorithm for determining the best performing combination of hyper
parameters is used.
[062] Secondly, a neural network cross validation design method may be used. In this case,
instead of searching for an optimal set of hyper-parameters, only model performance
on each cross-validation set is recorded to judge the model generalizability skill. Lastly,
a linear regression cross validation design may be used. In this case, in linear regression,
an ordinary least squares algorithm is executed, which does not require hyperparameter
tuning. However, in order to handle overfitting, a ridge regression is performed to
introduce regularisation in the linear model. The ridge regression in “sklearn” python
library, supports cross validation implementation. This way, a model generalisation
capability is better understood with the support of overfitting avoidance.
[063] The Embodiments herein also disclose integrating training experiments with model
versioning systems. Typically, the data science projects are experimental in nature, and
involve a lot of different activities such as data analysis, cleaning and machine learning
model training and deployment. The model training stage specifically requires a lot of
different iterations and thus involves various things to track such as hyperparameters,
data split, error and accuracy performance on each different split i.e., train, validation
and test set. It is also possible to log the timestamp, i.e., time at which the training
experiment was executed. To facilitate this tracking and version control, a model
tracking tool is used. Using this tool, every single experiment may be tracked to reflect
and analyse model training in future. Most important advantage it provides is that the
entire process saves a lot of time and cost which otherwise would be spent on retraining
21
past experiments. At the same time, it stores all tracked data in a single place, which
provides good accessibility to conduct analysis of previous experiments.
[064] Embodiments herein further disclose the ordering process built upon forecasts and
customer’s replenishment cycle. The ordering process considers available stock,
forecasted sales/inventory and stock in transit. With this given information, ordering
quantity is determined depending on the replenishment cycle of the customer's
inventory planning. Ordering quantity is generated based on the following formula:
[065] Formula:
[066] 𝑂𝑄(𝑛 + 1) = 𝐹(𝑛 + 1) − [(𝑄𝑜𝐻(𝑑 − 1) + 𝑆𝐼𝑇(𝑑 − 1)) −
(∑
𝑛
𝑖=1 𝐹𝑖)]……equation (1)
[067] Where OQ is ordering quantity, F is forecast, QoH is stock in hand, SIT is stock in
transit, d-1 is the previous day, and n will be the replenishment cycle of the customer.
[068] Once the base model 204 is trained through the process mentioned above, the validation
forecast dataset N, 208 is generated by correlating the trained base model dataset, which
is the output of the base model training, and the validation feature dataset A, 206. The
validation dataset N, 208 from each of such base model 204 is further correlated with
the sales validation data features 206 produced in the feature engineering phase, the
trained sales validation datasets 202, and the sales validation data set actual sales as
dependent variables to generate sales data validation model. This model may be a linear
regression, neural network or gradient boosting - tree based model.
[069] FIG 3 is an exemplary block diagram depicting a process of generating a machine
learning model for sales test data set, according to an embodiment of the present
invention. In FIG 3, a stack of sales datasets 302 comprising trained sales datasets
310A-N and its corresponding validation dataset 312A-N, identified to be relevant, are
retrieved from a database. The retrieved stack of sales datasets 302 are then fed to a
base model 304 for training. The base model 304 is similar to that of base model 204
as described in FIG 2. Further, the base model 304 is trained using the process as
described in FIG.2. Once this base model 304 is trained, the test forecast dataset N,
308 is generated by correlating the output of the base model 304 with the test feature
dataset A, 306. The test feature dataset A, 306 here is created on the fly, which is real
time based on historical data and a pre-defined feature engineering process, resulting in
generation of sales test data features. This test forecast dataset N, 308 from each of such
22
base model 304 is further correlated with the sales test data features 306 produced in
the feature engineering phase to generate sales data test model. This model may be a
linear regression, neural network or gradient boosting tree based model.
[070] FIG 4 is an exemplary block diagram depicting a process of predicting a sales forecast
value for a defined time period, according to an embodiment of the present invention.
In FIG 4, a stack of validation dataset 402 and a validation feature dataset B, 406,
identified to be relevant are retrieved from the database. The stack of validation dataset
402 comprises validation feature dataset A, 412, and the validation forecast dataset N
414A-C. The validation forecast dataset N, 414A-C includes validation forecast dataset
N from linear regression 414A, validation forecast dataset N from neural network 414B,
and validation forecast dataset N from gradient boosting tree (LGBM) 414C. The
validation feature dataset B, 406 is derived by sales validation data features generated
at a feature engineering stage as described above. Upon retrieving, a suitable
metamodel 404 from a list of metamodel is selected. The retrieved stack of validation
dataset 402, the stack of test dataset 408 and the validation feature dataset B 406 are
then fed to the selected metamodel 404. For example, a Support vector Regression
(SVR) may be used as a meta model. For metamodel 404 training, training data
including validation set features, validation set forecasts from each base model, along
with validation set actual sales as dependent variables are used. Using this training data,
the SVR model is trained. For prediction data, test set features, test set forecasts from
each base model are used. Once the metamodel 404 is trained, predicted sales forecast
value is computed or generated by correlating the output of the metamodel 404 with a
stack of test dataset 408, identified to be relevant are retrieved from the database. The
stack of test dataset 408 comprises test feature dataset A, 416 and test forecast dataset
N 418A-C. the test forecast dataset N 418A-C further includes test forecast dataset N
from linear regression 418A, test forecast dataset N from neural network 418B, and test
forecast dataset N from LGBM 418C. This predicted sales forecast value is desired
forecasts generated from model ensemble strategy.
[071] FIG 5 is a process flowchart illustrating an exemplary method 500 of forecasting
demand for a retail organization, according to an embodiment of the present invention.
At step 502, a real time sales input datasets associated with one or more products is
obtained from one or more data sources via a network. The real time sales input datasets
comprises categories of sales information classified as product identification data
category, sale performance data category, sales transactional data category, sales
23
resource data category, sales period data category and revenue level data category. At
step 504, the real time sales input datasets associated with one or more products are
preprocessed. At step 506, sales data features associated with the preprocessed real time
sales input datasets are generated by analyzing a sales data trend of each of the
preprocessed real time sales input datasets. The sales data features comprises sales
validation data features and sales test data features. At step 508, a machine learning
model for validation data set is generated based on the generated sales data features.
The machine learning model for validation data set represents a correlation between the
sales validation data features, sales validation forecast data set, and sales validation data
set actual sales as dependent variables. At step 510, a machine learning model for sales
test data set is generated based on the generated sales data features. The machine
learning model for sales test data set represents a correlation between the sales test data
features and sales test forecast data set. At step 512, a sales forecast value for a defined
time period is predicted based on the generated machine learning model for test and
validation sets. At step 514, the predicted sales forecast value is outputted on a user
interface of a computing device.
[072] The method 500 can be implemented in any suitable hardware, software, firmware, or
combination thereof.
[073] FIG 6A-E is a graphical representation of one or more exemplary sales forecast trends,
according to an embodiment of the present invention. FIG 6A is a graphical
representation of sales trend analysis on a yearly basis. The black line in the graph
represents a rolling average of the sales value with a window size of 365 days, and this
line gradually moves upward witnessing an increasing trend. FIG 6B is a graphical
representation of box plot analysis on a monthly basis. In this case, the yearly season is
represented by box-plot month wise for apparel product sales. The X-axis represents
the month from January to December. This box plot clearly shows the impact of major
holidays on sales volume in specific months. For example, Diwali holiday falls
somewhere in October month and the plot clearly reveals that in the third last plot
corresponding to October has low median sales and overall sales volume is increased.
The same effect can be seen in the month of February and March. The same effect is
also present in other categories as well such as Churidar, Pyjama and so on. FIG 6C is
a graphical representation of box lot analysis on a weekly basis. In this case, the weekly
season is represented by box plot weekday wise for all product sales (combined). It can
be observed that sales increase on weekends (i.e., corresponding to five and sixth
24
Saturday and Sunday in X axis.) FIG 6D is a graphical representation of distribution
plot analysis representing distribution of weekly sales (non-zero only) taking place in a
specific time period for all products across the company. FIG 6E is a graphical
representation of distribution plot analysis for selling prices for all products across
categories / stores.
[074] The written description describes the subject matter herein to enable any person skilled
in the art to make and use the embodiments. The scope of the subject matter
embodiments is defined by the claims and may include other modifications that occur
to those skilled in the art. Such other modifications are intended to be within the scope
of the claims if they have similar elements that do not differ from the literal language
of the claims or if they include equivalent elements with insubstantial differences from
the literal language of the claims.
[075] The embodiments of present disclosure herein address the unresolved problem of
accurately forecasting demand for a retail organization without human intervention.
The embodiment thus provides a platform which automates the process of prediction of
sales forecast.
[076] The embodiments herein can comprise hardware and software elements. The
embodiments that are implemented in software include but are not limited to, firmware,
resident software, microcode, etc. The functions performed by various modules
described herein may be implemented in other modules or combinations of other
modules. For the purposes of this description, a computer-usable or computer readable
medium can be any apparatus that can comprise, store, communicate, propagate, or
transport the program for use by or in connection with the instruction execution system,
apparatus, or device.
[077] The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or
semiconductor system (or apparatus or device) or a propagation medium. Examples of
a computer-readable medium include a semiconductor or solid-state memory, magnetic
tape, a removable computer diskette, a random-access memory (RAM), a read-only
memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical
disks include compact disk-read only memory (CD-ROM), compact disk-read/write
(CD-R/W) and DVD.
[078] Input/output (I/O) devices (including but not limited to keyboards, displays, pointing
devices, etc.) can be coupled to the system either directly or through intervening I/O
controllers. Network adapters may also be coupled to the system to enable the data
25
processing system to become coupled to other data processing systems or remote
printers or storage devices through intervening private or public networks. Modems,
cable modem and Ethernet cards are just a few of the currently available types of
network adapters.
[079] A representative hardware environment for practicing the embodiments may include a
hardware configuration of an information handling/computer system in accordance
with the embodiments herein. The system herein comprises at least one processor or
central processing unit (CPU). The CPUs are interconnected via system bus to various
devices such as a random-access memory (RAM), read-only memory (ROM), and an
input/output (I/O) adapter. The I/O adapter can connect to peripheral devices, such as
disk units and tape drives, or other program storage devices that are readable by the
system. The system can read the inventive instructions on the program storage devices
and follow these instructions to execute the methodology of the embodiments herein.
[080] The system further includes a user interface adapter that connects a keyboard, mouse,
speaker, microphone, and/or other user interface devices such as a touch screen device
(not shown) to the bus to gather user input. Additionally, a communication adapter
connects the bus to a data processing network, and a display adapter connects the bus
to a display device which may be embodied as an output device such as a monitor,
printer, or transmitter, for example.
[081] A description of an embodiment with several components in communication with each
other does not imply that all such components are required. On the contrary, a variety
of optional components are described to illustrate the wide variety of possible
embodiments of the invention. When a single device or article is described herein, it
will be apparent that more than one device/article (whether or not they cooperate) may
be used in place of a single device/article. Similarly, where more than one device or
article is described herein (whether or not they cooperate), it will be apparent that a
single device/article may be used in place of the more than one device or article or a
different number of devices/articles may be used instead of the shown number of
devices or programs. The functionality and/or the features of a device may be
alternatively embodied by one or more other devices which are not explicitly described
as having such functionality/features. Thus, other embodiments of the invention need
not include the device itself.
[082] The specification has described a method and a system for performing context-based
application disablement on an electronic device. The illustrated steps are set out to
26
explain the exemplary embodiments shown, and it should be anticipated that ongoing
technological development will change the manner in which particular functions are
performed. These examples are presented herein for purposes of illustration, and not
limitation. Further, the boundaries of the functional building blocks have been
arbitrarily defined herein for the convenience of the description. Alternative boundaries
can be defined so long as the specified functions and relationships thereof are
appropriately performed. Alternatives (including equivalents, extensions, variations,
deviations, etc., of those described herein) will be apparent to persons skilled in the
relevant art(s) based on the teachings contained herein. Such alternatives fall within the
scope and spirit of the disclosed embodiments. Also, the words "comprising," "having,"
"containing," and "including," and other similar forms are intended to be equivalent in
meaning and be open-ended in that an item or items following any one of these words
is not meant to be an exhaustive listing of such item or items or meant to be limited to
only the listed item or items. It must also be noted that as used herein and in the
appended claims, the singular forms “a,” “an,” and “the” include plural references
unless the context clearly dictates otherwise.
[083] Finally, the language used in the specification has been principally selected for
readability and instructional purposes, and it may not have been selected to delineate or
circumscribe the inventive subject matter. It is therefore intended that the scope of the
invention be limited not by this detailed description, but rather by any claims that issue
on an application based here on. Accordingly, the embodiments of the present invention
are intended to be illustrative, but not limiting, of the scope of the invention, which is
set for.

We Claim:
1. A system (100) for forecasting demand for a retail organization, the system (100)
comprising:
a hardware processor (102); and
a memory (106) coupled to the processor (102), wherein the memory (106) comprises
a set of program instructions in the form of a plurality of subsystems, configured to be
executed by the processor (102), wherein the plurality of subsystems comprises:
a sales data gathering subsystem (108) configured to obtain real time sales input
datasets associated with one or more products from one or more data sources via a network,
wherein the real time sales input datasets comprises categories of sales information
classified as product identification data category, sale performance data category, sales
transactional data category, sales resource data category, sales period data category and
revenue level data category;
sales data preprocessing subsystem (110) configured to preprocess the real time sales
input datasets associated with one or more products;
sales data feature generation subsystem (112) configured to generate sales data features
associated with the preprocessed real time sales input datasets by analyzing a sales data
trend of each of the preprocessed real time sales input datasets, wherein the sales data
features comprises sales validation data features and sales test data features;
sales data validation model training subsystem (114) configured to generate a machine
learning model for validation data set based on the generated sales data features, wherein
the machine learning model for the validation data set represents a correlation between the
sales validation data features, sales validation forecast data set, and sales validation data set
actual sales as dependent variable;
sales data testing model training subsystem (116) configured to generate a machine
learning model for sales test data set based on the generated sales data features, wherein
the machine learning model for sales test data set represents a correlation between the sales
test data features and sales test forecast data set; and
sales forecast prediction subsystem (118) configured to predict a sales forecast value
for a defined time period based on the generated machine learning model for sales test data
set and validation datasets.
2. The system (100) as claimed in claim 1, wherein in preprocessing the real time sales input
datasets associated with the one or more products, the sales data preprocessing subsystem
(110) is configured to:
analyze the real time sales input datasets associated with the one or more products;
extract relevant sales input datasets from the analyzed real time sales input datasets
based on one or more predefined rules;
normalize the extracted relevant sales input datasets using a relevant sales data scaling
technique; and
classify the normalized sales input datasets into trained sales validation datasets and
sales test datasets based on the time period required for the validation and test set.
3. The system (100) as claimed in claim 1, wherein in generating the sales data features
associated with the preprocessed real time sales input datasets by analyzing the sales data
pattern of each of the obtained real time sales input datasets, the sales data feature
generation subsystem (112) is configured to:
detect a sales data pattern for each of the preprocessed real time sales input datasets
using one or more pattern analysis rules;
determine one or more sales data attributes corresponding to the detected sales data
pattern by correlating the detected sales data pattern with the real time sales input datasets;
and
generate sales data features associated with the preprocessed real time sales input data
set based on the determined one or more sales data attributes.
4. The system (100) as claimed in claim 1, wherein in training the machine learning model
based on the generated sales data features, the sales data validation model training
subsystem (114) is configured to:
determine a correlation between the sales validation data features and the trained sales
validation datasets using a base machine learning model;
generate the sales validation forecast data set based on the determined correlation
between the sales validation data features and the trained sales validation datasets; and
train the machine learning model for validation data set based on the generated sales
validation forecast data set, wherein the machine learning model for the validation data set
represents the correlation between the sales validation data features, the trained sales
29
validation datasets, the sales validation forecast data set from each base model, and the
sales validation data set actual sales as dependent variable.
5. The system (100) as claimed in claim 1, wherein in generating the machine learning model
for sales test data set based on the generated sales data features associated with the real
time sales input datasets, the sales data testing model training subsystem (116) is configured
to:
determine a correlation between the sales test data features and the sales test datasets
combined with the corresponding sales validation data features using a base machine
learning model;
generate the sales test forecast data set based on the determined correlation; and
generate the machine learning model for sales test dataset based on the generated sales
test forecast data set, wherein the machine learning model for sales test data set represents
the correlation between the sales test data features, and the sales test forecast data set from
each base model.
6. The system (100) as claimed in claim 1, wherein in predicting the sales forecast value for
the defined time period based on the trained machine learning model for sales test dataset
and validation datasets, the sales forecast prediction subsystem (118) is configured to:
train a meta model using the sales validation forecast data set, the sales validation data
features, and the sales validation data set actual sales as a dependent variable derived from
the machine learning model for validation data set;
determine a correlation between the trained meta model datasets and the sales test data
features, the sales test forecast data set derived from the machine learning model for sales
test data set; and
predict the sales forecast value for the defined time period based on the determined
correlation.
7. A method (500) for forecasting demand for a retail organization, the method (500)
comprising:
obtaining, by a processor (102), real time sales input datasets associated with one or
more products from one or more data sources via a network, wherein the real time sales
input datasets comprises categories of sales information classified as product identification
30
data category, sale performance data category, sales transactional data category, sales
resource data category, sales period data category and revenue level data category;
preprocessing, by the processor (102), the real time sales input datasets associated with
one or more products;
generating, by the processor (102), sales data features associated with the preprocessed
real time sales input datasets by analyzing a sales data trend of each of the preprocessed
real time sales input datasets, wherein the sales data features comprises sales validation
data features and sales test data features;
generating, by the processor (102), a machine learning model for validation data set
based on the generated sales data features, wherein the machine learning model for
validation data set represents a correlation between the sales validation data features, sales
validation forecast data set, and sales validation data set actual sales as dependent variable;
generating, by the processor (102), a machine learning model for sales test data set
based on the generated sales data features, wherein the machine learning model for sales
test data set represents a correlation between the sales test data features and sales test
forecast data set;
predicting, by the processor (102), a sales forecast value for a defined time period based
on the generated machine learning model for sales test data set and validation datasets; and
outputting, by the processor (102), the predicted sales forecast value on a user interface
of a computing device (100).
8. The method (500) as claimed in claim 7, wherein preprocessing the real time sales input
datasets associated with the one or more products comprises:
analyzing the real time input sales datasets associated with the one or more products;
extracting relevant sales input datasets from the analyzed real time sales input datasets
based on one or more predefined rules;
normalizing the extracted relevant sales input datasets using a relevant data scaling
technique; and
classifying the normalized sales input datasets into trained sales validation datasets and
sales test datasets based on the time period required for the validation and test set.
9. The method (500) as claimed in claim 7, wherein generating the sales data features
associated with the preprocessed real time sales input datasets by analyzing the sales data
pattern of each of the obtained real time sales input datasets comprises:
31
detecting a sales data pattern for each of the preprocessed real time sales input datasets
using one or more pattern analysis rules;
determining one or more sales data attributes corresponding to the detected sales data
pattern by correlating the detected sales data pattern with the real time sales input datasets;
and
generating sales data features associated with the preprocessed real time sales input data
set based on the determined one or more sales data attributes.
10. The method (500) as claimed in claim 7, wherein generating the machine learning model
for validation datasets based on the generated sales data features, comprises:
determining a correlation between the sales validation data features and the trained sales
validation datasets using a base machine learning model;
generating the sales validation forecast data set based on the determined correlation
between the sales validation data features and the trained sales validation datasets; and
training the machine learning model for validation data set based on the generated sales
validation forecast data set, wherein the machine learning model for validation data set
represents the correlation between the sales validation data features, the trained sales
validation datasets, the sales validation forecast data set from each base model, and the
sales validation data set actual sales as dependent variable.
11. The method (500) as claimed in claim 7, wherein generating the machine learning model
for sales test data set based on the generated sales data features associated with the real
time sales input datasets, comprises:
determining a correlation between the sales test data features and the sales test datasets
combined with the corresponding sales validation data features using a base machine
learning model;
generating the sales test forecast data set based on the determined correlation; and
generating the machine learning model for sales test data set based on the generated
sales test forecast data set, wherein the machine learning model for sales test data set
represents the correlation between the sales test data features, and the sales test forecast
data set from each base model.
32
12. The method (500) as claimed in claim 7, wherein predicting the sales forecast value for the
defined time period based on the generated machine learning model for sales test dataset
and validation datasets comprises:
training a meta model using the sales validation forecast data set, the sales validation
data features, and the sales validation data set actual sales as a dependent variable derived
from the machine learning model for validation dataset;
determining a correlation between the trained meta model datasets and the sales test
data features, the sales test forecast data set derived from the machine learning model for
sales test data set; and
predicting the sales forecast value for the defined time period based on the determined
correlation.