|
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
Lately, a few users have been asking how does Lokad handle an exceptional sales that won't be happening again anytime soon? This issue is usually known as outliers management: how to deal with data points that are completely off compared to the other
... [More]
points.
Lokad is only looking at historical data, and since we don't know that the exceptional sales aren't going to happen again (expert knowledge), this event is going to be interpreted as "real" sales, leading to potentially over-estimated sales forecasts. This situation is a typical case of demand forecasts vs. sales forecasts.
At this point, the natural solution would be to give the user the possibility to adjust the historical data to truly reflects the demand. We are currently working on a solution dedicated to safety stock calculations that would handle this sort of situations. Stay tuned. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
In a previous post, I have been discussing the various worlds of forecasting software, outlining 3 main categories Deterministic simulation software Expert insights aggregation software Statistical forecasting software Lokad
... [More]
is clearly a member of the third category. Although, those three categories are not really competing with each other since they are usually not suited for the same type of situations.
In the second category, insight aggregation software, prediction markets software seems to attract more and more interest. Jed Christiansen has a very interesting review of prediction markets software
The overview page of Inlink provides an insightful summary about prediction markets
Prediction markets enable a diverse group of people to predict the answer to a question by buying and selling shares in stocks representing the possible answers. Using a stock market-like mechanism allows people to express their opinion as a "weighted vote" over time in response to new information or a change of opinion. And unlike a poll, a prediction market is asking "what will happen?" vs. "what do you want to happen?"
For example, if we ask the question: "Who will win the singing contest?" The four contestants would be represented as stocks that people buy shares in. If "Contestant A" has a stock price of $56, that means "the crowd" thinks there is a 56% chance that contestant will win. When people buy shares in that contestant, the price goes up. When they sell shares in that contestant, the price goes down. The stock price of an answer represents the probability of that answer being correct, priced stock after a period of time is considered the groups answer to the question posed.
The main difference with classical insight aggregation software is that the participants are financially involved in getting the right forecast.
Compared to Lokad (or to any statistical forecasting software), the main benefits of markets prediction is the ability to rationally tackle a forecast that depends on (potentially) irrational customer desires even when no relevant data is available. The crowd is bringing a solution to the small group of experts bias that usually plagues classical prospective methods such as the Delphi method.
Yet, like any insight aggregation method, market predictions involve quite an expensive forecasting process to get a single question answered. For example, it would not seem a very practical approach for call centers that requires 96 quarter-hour forecasts on a daily basis to predict inbound call volumes. If meaningful historical data is available, then statistical forecasts should be as accurate (if not more) and way much cheaper.
In its own statistical ways, Lokad is also (somehow) using the wisdom of the crowd, except that instead of considering a panel of people, we are considering a panel of business time-series that we exploit to improve the overall forecasting accuracy. In both cases, leveraging larger input datasets to improve forecasting accuracy is a key idea. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
Forecasting consists in producing figures that are supposed to reflect the future. But those figures depend heavily on the period chosen for data aggregation. Lokad supports the most frequently used periods: quarter-hour, half-hour, hour, day, week
... [More]
, month, quarter, semester, year ...
Intuitively, the longer the considered period, the easier it is to make an accurate forecast. For example, yearly forecasts eliminate seasonal variations. Although a short forecasting period might provide a false sense of accuracy (ex: forecasting daily candy sales over the next two years) whereas a large period might be unsuited to take operational decision (ex: trying to optimize the weekly worker schedules of the candy manufacturing unit based on yearly forecasts).
A careful choice of the forecasting period is essential to make the most of forecasting. Yet, surprisingly, this question is frequently left mostly unanswered in books treating the subject of forecasting for practitioners (usually focusing on sales or demand forecasting). Typical answers are most of the manufacturing industry is using monthly forecasts and many large retailers are using weekly forecasts.
Yet, simple assumptions can lead to practical quantitative clues to make this choice. If we just assume that forecast errors follow a normal distribution, then expected error increase when switching to a shorter period is
year → month: √(12/1) ≈ 3.5 (i.e. error multiplied by 3.5)
month → week: √(31/7) ≈ 2.1 (assuming a month with 31 days)
week → day: √(6/1) ≈ 2.5 (assuming 6 business days per week)
hour → quarter-hour: √(4/2) = 2
Although, the normal distribution assumption is usually not exactly verified, those figures are quite representative of most situations. Those figures can be used to evaluate the opportunity to change the forecasting period if the forecast error is too high or if the forecast period is too long. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
Lokad has a pretty unique approach to forecasting where we leverage all the data that we have to perform every single forecast. While discussing with customers, I have been asked whether Lokad would mix Chinese food data with sports bar data. Indeed
... [More]
, the customer was worried that we might mix data that exhibits very different sales patterns although it was the same food and drink retail industry.
In fact, the more abstract question was: How refined is the notion of industry segments within Lokad? Well, the real answer is that we don't have any notion of industry segments in Lokad. And, in my humble opinion, it would be a really poor idea to even try to improve statistical forecasts based on such information
No matter how refined is your industry segments classification, it's still a very poor approximation of the reality. Industry segments are changing all the time, and who knows whether sales of Thai food exhibit the same patterns that sales of Vietnamese food. In a way, this is why dmoz.org is massively less popular and useful than search engines.
Even of small point of sales is usually generating a dozen of time-series (for each product being sold) at least 200 worked days per year. Thus, one year of history represent already more than 1.000 numbers to be exploited. The information contained in those number is dwarfing the amount of information contained in the classification that would typically be represented as just a few numbers.
Creating a classification that matches the forecasting purposes is probably as hard, if not harder, than the forecasting task itself. Indeed, an efficient classification would be able tell whether business segments will exhibit same patterns in the future.
Instead of relying on such a manual classification, Lokad is relying directly on statistical correlations: if some data can be used to improve the considered forecast, then do it; if the data cannot be used to achieve that, then just ignore the data. With proper statistical tools, more data does not hurt and storing data has never been cheaper.
Back to the Chinese Food vs. Sport Bar initial example, the reality is more complex than it seems. Some products, sold in both places, let's say ice cream, might exhibit similar sales patterns because they depend a lot from the weather, while some others, let's say beers, might behave very differently. Lokad is relying on automated processes to validate the correlations for every single forecasts; as opposed to do it once for a whole industry segment.
Introducing industry segments in Lokad would be like reverting from full text search to a hierarchical directory: time-consuming, and, in the end, much less efficient. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
Lokad can be accessed programmatically through our web services. We are already providing tutorials for quite a few languages, namely C#, Java, PHP and C . But we were not providing any Python tutorials so far, although there are several
... [More]
promising ERP implemented in Python. If you're not convinced, have a look at TinyERP and ERP5.
Thanks to Maxim Krikun, we have now a complete Python tutorial that explains how to use our Forecasting Web Services. As usual, the source code has been released as open source on SourceForge. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
We have just released the version 1.1 of Lokad Excel Sales Forecasting addin. This release comes with many bugfixes over the initial release. No new features have been added. Supporting all Excel versions starting from Excel 2000 up to Excel
... [More]
2007 proved to be a much more complicated task than we initially suspected. Excel versions are varying from one to another in many subtle ways, I apologize for the issues that some of you have been encountering with the initial release. We hope things will go more smoothly with this release.
As detailed in the changelog file:
Refactored the addin shim to use custom interop.
Bug fix for the UDF registration under Excel 2007.
Added a sample spreadsheet in Excel 2007 format.
Bug fix for incorrect separator handling of int. Excel versions.
Bug fix for the Lokad command bar that was loaded multiple times.
Improving behavior when UDF can't be parsed.
Bug fix for the providers required an option.
Removing deprecated overload from ForecastSales.
Improving behavior when ForecastSales args are incorrect.
Fixing a bug that was blocking Excel 2000 users.
Never hesitate to contact the support if you encounter any issue with the Lokad products. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
Accurate forecasts are critical because each extra-percent of forecast error comes with a steep price, literally. Indeed, when the costs associated to forecast errors are usually supra-linear, or put more simply, the costs associated to forecast
... [More]
errors increase much faster than the error itself.
As a simple example, a greater forecast error increases the need for safety stocks and thus working capital requirements. But if the working capital goes too high, bank interests start to rise, leading to even more expensive safety stocks.
But there are also more subtle negative consequences: past forecast errors may lower future accuracy. Indeed, historical demand itself is rarely known, instead, we usually rely on the historical sales data as an efficient approximation of the demand. Yet, this approximation is not perfect. For example, a stock-out prevents any sale to be made for a particular product. Yet, in case of a stock-out, zero sale does not equate zero demand.
For statistical forecasting algorithms, that relies on time-series analysis, it can be quite hard, using the sole sales data, to distinguish a zero sale caused by a stock-out from a zero demand. As a result, a lot of stock-outs (as they lead to lower sales) can be statistically interpreted as a lower demand; which, eventually, generates even more stock-outs.
Increasing your forecast accuracy now is one of the key to increase the forecast accuracy tomorrow. Accurate forecasting is not the destination but the journey. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
The Lokad forecasting technology is accessible through our Forecasting API. We already had published tutorials for C#, Java and PHP. Thanks to the contribution of Tomasz Szulist, we have just published a new tutorial for C . As usual, the
... [More]
source code is available as open-source on SourceForge. In order to communicate with SOAP, we have been using the excellent gSOAP toolkit. Check-it out. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
Sometimes, I am referring to statistical learning and some other time, I am referring to statistical forecasting. In the situation of Lokad, the two terms means roughly the same thing: the statistical theory used to produce the time-series
... [More]
forecasts.
Beyond the narrow scope of the Lokad, statistical learning refer to a more general theory that actually includes time-series forecasting, but also the wide spectrum of applications that can be found in machine learning.
Also, statistical forecasting is distinguished from forecasting (no adjective here), because historical data analysis is only one of the approaches that can be used to forecast the future. [Less]
|
|
Posted
over 5 years
ago
by
Joannes Vermorel
In retail, the ultimate goal of sales forecasting is usually to calculate optimal safety stocks. Unfortunately, most online resources do give much detail about the explicit algorithms that should be used for safety stocks. In order to
... [More]
facilitate the task for customers and partners (and competitors :-), I have just published an extensive guide Calculate safety stocks with sales forecasting. The guide is illustrated with a Microsoft Excel spreadsheet.
The intent of this guide is to be a valuable piece of information for practitioners. I have pushed some efforts in order to make it independent from the Lokad forecasting technology (thus, you can grab your favorite forecasting tool, and re-use the formulas as such). [Less]
|
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.